PGPやGnuPGには近年いくらかの批 判もありますが、開発は情熱的に続いています。
とはいえ、GnuPGは20年以上の開発によって内部構造が複雑になりすぎています。これに伴う種々の問題に取り組むため、NeoPGという新たなプロジェクトが発足しています。
スライドによると、GnuPGは49万行のコードから成り、400近くのコマンドラインオプション、2種類のOpenPGPパーザ、自前のHTTPクライアントやDNSリゾルバ関連コードを持つ、重厚長大なプロジェクトです。NeoPGでは、できるだけレガシーコードを減らし、外部ライブラリを積極的に利用することで、開発を容易にするつもりです。スライドの時点で、すでに行数はほぼ半減し、コマンドラインオプションも120ほど減っているそうです。
ブログでは、そのほかにもautoconfではなくCMake、CPPマクロではなくC++テンプレート、数多くの小さなバイナリではなく単一バイナリ、長生きするデーモンではなく、すぐ終了するヘルパープロセスといった劇的な設計変更の理由について説明しています。(このうちの一部はUNIX哲学からの逸脱と見られかねないことも理解したうえで、使い勝手や開発/メンテナンスのコスト、コンピュータ性能の発達などを考慮した結果とのことです。)
ライセンスについても、GitHubのREADME.mdによれば「今のところGPLやLGPLなど様々なライセンスのコードを含んでいるが、新規コードはSimplified BSDライセンスに限っている」という書き方からして、GPLからの脱却を目指しているようです。
全体的に、ここ10年程度のトレンドを慎重に取捨選択して、そつなくリファクタリングしているように見えますが、皆さまはどう評価されるでしょうか。

GnuPG のバージョン 2.2.0 がリリースされました。これは長らく modern 版として開発されてきた 2.1 系が新たな安定板になったことを意味します。2.0 系は今年いっぱいでサポートが終わるので、ユーザは 2.2 へ移行する必要があります。

systemd のユニットファイルで User=0sdn のような指定をすると、0sdn という名前のユーザーが存在してもしなくても、0sdn ではなく root として実行されるそうです。これは systemd のバグでしょうか。それとも設定ファイルが間違っているだけでしょうか。 報告を受けた systemd 開発者の Lennart Poettering 氏は、「十進数から始まるユーザー名が不正なのであって systemd のバグではない」と主張します。しかし、そのようなユーザー名が useradd では問題なく作成できたり、adduser でも設定により作成できると指摘され、氏はこう返答しました。「(1) systemd は色々なシステムで動くようにするため、制限が厳しいこともある。(2) ユニットファイルに User= で指定するユーザー名は一般ユーザーではなくシステムユーザーであるから、厳しく制限して当然。(3) systemd では、文法エラーはログしてスルーというポリシーである。」

つまり、ユーザー名が間違っているだけなら fatal error として停止するが、十進数で始まる名前は文法的エラーなので、ログだけ取って実行は続け、それゆえに root として実行されるということです。この点、開発者が「バグはない」と言い張る一方で、ユーザー名を認識できないバグと、そのまま root で動くバグの二つだろうという意見もあります。

あまり関係ありませんが、ついでに systemd は名前解決のコードにもバグがあり、バージョン 223 以降、つまりここ 2 年ほどの間の systemd は TCP ペイロードの細工により任意のコード実行まで可能かもしれない脆弱性がありました。systemd-resolved がデフォルトで起動されるシステムはあまり多くないようですが、ご注意ください。

Windows の未公開コード類が流出していたそうです。(slashdot)

流出していたのは Shared Source Kit で、ごく一部の開発者にライセンスされているものです。ドライバなど低レベル (つまり高位な権限) で動作する部分のコードも含まれるため、一般には参照できません。また同時に、Windows 10 や Server 2016 の未公表ビルドも入手できる状態になっていたそうですが、これらはチーム内でのみ使用されるはずのものです。

データがアップロードされていた Beta Archive からは既に削除されていますが、内部のコードやデバッグシンボル付きバイナリがあれば、ゼロデイ攻撃などが容易になりかねません。実際に2004年の流出は脆弱性の発見に繋がりました。

スタックが伸びすぎるとどうなるのか、という疑問は誰しも考えたことはあるでしょう。
実際にスタック範囲を他のメモリ領域と衝突させて悪用できることが 2005 年と 2010 年に示され、対策が取られてきました。
しかしセキュリティ企業 Qualys は 19 日、少なくとも Linux, OpenBSD, NetBSD, FreeBSD, Solaris の i386 と amd64 では対策の不備があり、実際に悪用可能か、少なくとも PoC が存在することを示しました。(ITmediaの日本語記事)
数多くの入口からローカル権限上昇攻撃ができた (あるいは理論上可能な道筋がある) そうです。
緩和策としては limits.conf 等でスタックを制限することなどがありますが、完全ではありませんし副作用も大きいです。各ベンダーには既に通知され、順次対策が取られることになっていますので、アップデートの用意をしておくのが最善でしょう。
アドバイザリによれば、Debian でも 8.5 と 8.6, また 8.x と 9 以上の間には脆弱さに大きな違いがあり、最新のものほど効率よく悪用することは難しくなってきているそうです。
しかし現状で最も簡単に悪用できる方法は i386 の Debian で Exim を使ってローカル権限上昇をすることだ、と Qualys は指摘しています。
また OpenBSD では at を使って攻撃しようとしたものの、ファイルシステムが遅すぎて、一週間かけてもヒープがスタックに届くほどの数のジョブファイルを作成できなかったそうです。
なお、今回は 64bit でもスタックと他領域が近い場合があることも示されましたが、基本的にはメモリ領域が広い方が安全です。
grsecurity/PaX にはスタック・ガードページの大きさを変更できる機能があるので、これを大きくするのは簡単で有効です。また GCC には -fstack-check というオプションがあり、各 4KB ページにアクセスすることで、スタックポインタが他領域に行ってしまう前に必ずガードページに当たり、SEGV になってくれるそうです。パフォーマンスに影響はありますが、長期的には良い方法だと Qualys は指摘しています。

Debian 9 の初めてのバージョンが 17 日にリリースされました。
8.0 "Jessie" から 2 年も経っていますし、7.x "Wheezy" の LTS があと 1 年未満ですから、既存ユーザがアップデートする良い機会になりそうですね。
また、Live イメージには Cinnamon や Mate 版もありますので、新規に試してみたい人のハードルも低くなっています。
タレコミ時点では、 https://www.debian.org/CD/http-ftp/ にある日本のミラーサーバのうち jaist と hanzubon しか 9.0 を持っていないようですが、 http://debian-cd.debian.net/ を使うと自動的に近場からダウンロードできます。また、Debian は BitTorrent の使用を推奨していますので、利用できるならそちらをどうぞ。( https://www.debian.org/distrib/ )
LXDE の Live イメージを起動してみたところ、日本語を選択しても、いきなり ClipIt のダイアログが英語で出てきたので、これは英語を読めない人には勧められないな、と思いました。

江戸期以前の「くずし字」を80%以上の精度でテキストデータにできる技術が開発されたそうです。東京大学大学院教授のロバート キャンベル氏によると、「欧米諸国とちがって、日本人は自らの歴史風土を自在に行き来する能力を失った」という特殊事情がありますが、この技術は、その能力を取り戻すきっかけになるかもしれません。