Not only is the Internet dead, it's starting to smell really bad.:2017年04月下旬

2017/04/21(Fri)

[旅行] 群馬県立森林公園 さくらの里

一昨年以来なんだけど 群馬県立森林公園 さくらの里に花見に行ってきたよ、妙義山の奇岩の麓に咲き乱れるソメイヨシノ、オオヤマザクラ、ヤエベニはいいぞ。

管理センター周辺のソメイヨシノは散りはじめで今週末がラストチャンス、土日には盛大な桜吹雪を散らしてシーズン終了と思われます。 でもソメイヨシノが終っても月末からGWにかけては寒山なんかの八重桜がまた見頃を迎えるので5月上旬一杯は楽しめます。 5/3には妙義山下仁田さくら祭というのをやってるそうです。

ただしメチャクチャ交通の便が悪い所なのよね、自家用車持ってるブルジョアならいいけど。 はるか昔に駐車場で腐らせてたインテグラを廃車にしたプアーとしましてはなかなか行くのが厳しい場所です。

さくらの里の最寄駅は上信電鉄の下仁田駅なんだけど、ワイの最寄り駅の大船駅から行くとすると 東京上野ラインの始発5:09に乗れば下仁田駅には9:23に到着するんですが、妙義山登山口(下仁田側)を通るバス(しもにたバス中之岳線)は9:20発ですでに出てしまった後で 次のバスは11:40まで無いのよね、駅前のタクシー使って駐車場まで4,000円前後かかってしまいます。

このバスに乗るためにはプラス2,990円で新幹線(とき301号)で加速キメれば8:15には着くんだけど、タクシー料金との差がわずかな上に なーんもない駅前でバス待ちに一時間以上潰さないとならんのが困りもの。

これ出発地が横浜駅なら京浜東北線の始発4:22に乗って上野から高崎線乗れば特急料金無しで8:15分着なんだよな、やはり横浜以南には人権は無い。

あとバスにはもういっちょ問題あります、料金は200円で安いのですが中村停留所で降りてすぐの妙義山登山口(下仁田側)からさくらの里までは1時間弱の登り路なので、体力の無い人は厳しいです。

なので今回は高崎から上信電鉄乗って下仁田駅に出るのではなく、信越本線に乗換で松井田駅に出てみました。 松井田からさくらの里まではタクシー以外足はなくやっぱり4,000円弱かかってしまうんですが、新幹線使わずとも8:26には松井田駅には到着できるので1時間も時間的余裕があるという。 なのでこのコースが一番コスパいいかな、なおタクシーは下仁田駅とは違って駅前に常駐してないので事前に予約しておいた方がスムーズにいきます。

ただし管理センターには9時には到着してしまうので、この時間だと妙義山側は順光で綺麗なんですが 管理センターにある展望台のハイライトである金鶏山をバックにしたソメイヨシノはちょうど逆光の時間帯なんですな。

時刻と光線の関係からするとやっぱり下仁田側からさくらの里の管理センターまで山昇ってくルートの方がいいんだけどね。 まぁ体力あれば一度下まで降りてまた登ってりゃいいんですが。

帰りはリッチマンならまた松井田駅からタクシー迎車すればいいのですが、ワイはプアーなもんで(念押し)財布に優しく今度こそしもにたバス中之岳線に乗って帰ります。 さっきも書いた通りさくらの里からバス停までは1時間くらい歩かないとならないのと、最終バスの時刻が15:49(土日は15:46)とクソ速いので15:00前には下山をはじめないとならんのが難点。 まぁ山間部だし15:00過ぎたら光線の具合的に写真撮影も切り上げ時でもあるのでええわもう。ちなみにこの最終バスはスクールバス扱いなので無料です。

この最終バスは16:08に下仁田駅着なんですが、また上信電鉄との連絡が悪くて16:00発高崎行は出てしまった後で、次の電車16:58分まで待たなければならんのも難点やね。 朝も3分差だったり帰りも8分差だったりと連絡が悪いというか、観光客には地元民の足は絶対に使わせないゾという意図を感じる…なお地元民もバスは使ってないもようでガラガラです。

別解としてさくらの里から妙義神社の方まで出れれば乗り合いタクシー(菅原線)の最終が18:06まであるんですが、さくらの里から妙義神社までは 中間道(関東ふれあいの道)の一本杉コースを通るちょっとした登山らしく時間が読めないのと、途中の金鶏橋が去年の台風で崩落中で通行できないということで諦めた。 一本杉コースを避けた場合は金鶏山をぐるっと周る県道196号をひたすら歩く感じっぽい、この道もさくらの里を一望に見下ろせていいんだけどね。

紅葉シーズンも良いそうなので今度は秋に行きたいんだけど、ここ数年の紅葉狩りは甲府の昇仙峡でな…

2017/04/22(Sat)

[音楽] MUTEMATH/Changes

完全に見過ごしてたんだけどMUTEMATHって最新アルバム「Vitals」の リミックスアルバムを半年前に出してたのね、しかも新曲入り。

配信オンリーなので全く気付かんかった、つーかyoutubeの公式チャンネルでろくに宣伝しなかったあたりメリケンでもyoutubeって日本のニコ動並みの腐乱死体なんじゃねぇの、まぁ残念でも無ければ当然なんだが。お勧めにいくら興味ない押してもクソみたいなチューバー動画チャンネルばっか出してきやがって。

しかしMUTEMATHは偶然にyoutubeで観たライブのヤバさでファンになったので、プロモーションの場としてのyoutube投げ捨ててしまったとしたらそれは感慨深いものがある。

たしか2007年くらいに友人から音出るオモチャや楽器を改造して変な音出すCircuit Bendingつー遊びが流行ってるときいて、検索したら関連動画かなんかにMUTEMATHのライブ映像が出てきたんだっけかな。またリアルタイムの音楽を聴いたりライブに足を運ぶようにになったきっかけでもある。

そういえば「Odd Soul」ツアーの時には突然 ニコ生でスタジオライブまでやってたし、動画サイトでのプロモーションを重視してた感があったけど、力入れてたのは本人たちでなく当時契約してたWarnerなんかねぇ。

とにかくMUTEMATHはライブが凄いバンドなんだけど、前作「Odd Soul」の完成が遅れるわメジャー契約切れてインディーに戻ったからか、新作「Vitals」出てから2年経っても全然来日しないよな。ホステスエンタあたり頑張ってくれんもんだろうか。いや声はかけてるけど来たがらないとか条件で折り合わないならしゃーないんだけども。

そもそも洋楽アーティストが来日するのは日本国内でのCD販売のプロモーションなわけだけど、アルバム「Vitals」も日本発売がぜんぜんアナウンス無いから輸入盤で買ってしまったよ、結局半年遅れで出たけど。

まぁ音ゲーかアニメの主題歌しか売れないし日本はもはや市場じゃないからなぁ。一部の洋楽好きはフジロックやらサマソニでフェスでいつものUKあたりのロートル共を出しときゃ満足だろうし。

2017/04/23(Sun)

[セキュリティ] Googleアカウントのバックアップ確認コード

先日スマホ(Nexus5)を置き忘れてしまったんですよな。

こいつGoogle認証アプリを入れて複数要素認証のトークン生成に使ってた端末なので、気づいて即

と雄叫びを上げながらバックアップコード使ってあらゆるサービスからMC5ならぬNexus5をキックアウトしないとならん羽目になってもうグッタリでございます。

ところが数あるサービスの中、なぜかGoogleアカウントだけ認証アプリのコード入力を求められた時に

ちゅーよくわからん状態。

いやーこれ乗っ取り済みでこっちがキックアウトされてんのかと思ったんだけど、そもそもロックにPIN4桁使わずクッソ長いパスコード毎回打ち込んでるパラノイアだし、その可能性はまず無いよなぁと。

結局「このマシンは頻繁にログインするから2段階認証をスキップ云々」なガバガバ設定のマシンが1台あったのでそれで助かったんだけど、これもWindows 10 Creator's Updateがここ最近頻繁にクラッシュするせいで、Chromeのプロファイルが壊れてたから昔のバックアップに戻したりで大変だった…

そんで活動履歴みたけど、紛失する直前までのワイのログしか残ってないし、やっぱりGoogleアカウント側がおかしかったんじゃないのかなと。

2016年3月頃に生成したバックアップコードは以下のような書式で、8桁(3+2+3形式)なんだよね。

バックアップ確認コード
<アカウント>@gmail.com

1. XXX XX XXX          6. XXX XX XXX
2. XXX XX XXX          7. XXX XX XXX
3. XXX XX XXX          8. XXX XX XXX
4. XXX XX XXX          9. XXX XX XXX
5. XXX XX XXX         10. XXX XX XXX

日付: CCYY/MM/DD hh:mm:ss

バックアップ コードをすべて使用してしまった場合は、次の URL で新しいコードを生成してください:
https://www.google.com/accounts/SmsAuthConfig
最新のセットのバックアップ コードのみが使用できます。

コードはすぐに取り出せる場所に保管してください。
各コードは 1 回のみ使用できます。

ところが今改めて再作成したら

バックアップ コードの保存
バックアップ コードはすぐに使える状態で安全な場所に保管しておいてください。

1. XXXX XXXX		 6. XXXX XXXX
2. XXXX XXXX		 7. XXXX XXXX
3. XXXX XXXX		 8. XXXX XXXX
4. XXXX XXXX		 9. XXXX XXXX
5. XXXX XXXX		10. XXXX XXXX

(<アカウント>@gmail.com)

* それぞれのバックアップ コードは 1 回しか使用しません。
* さらに必要な場合は https://g.co/2sv をご覧ください
* コードの生成日: CCYY/MM/DD

と、同じ8桁なんだけど4+4形式に代わってて、これを保存したら今度はちゃんと「別の方法でログインを」するで「8 桁のバックアップ コードのいずれかを入力する」が候補に出てくるようになった。

もしかすると互換性のない方法に代わって古い形式は無効にされたんですかね…コワイコワイ。

結論、定期的にバックアップコードが使えるか確認しとけですな、忘れがちだけどもファイルバックアップからリカバリができるか定期的に確認しておけと一緒。

2017/04/26(Wed)

[Mobile Phone] Nexus5見つかった

置いた場所がさっぱり思い出せなくて俺まで認知症かと思ったんだけど、やっぱ家の中にあった。 さすがに情報機器をお外に置き忘れるほど耄碌しとらんって…

しかしNexus5(2014年2月発売)も3年ちょい経って

とゴミになりつつあるんだけど

ということでもう二度とGoogle端末なんぞ買わねえよという気分なんですが、そもそもAndroid操作性ksだしな。

同じ時期に買ったiPhone5s(2013年9月発売)にはまだ最新のiOS10.3.1が降ってきるしまだしばらくはいけそうなんだけど、とはいえこいつも

とか問題ありありだしな、そもそも故障も多くこの3年間で

という羽目になってて、もう二度とクソサポートのApple端末なんぞ買わねえよという気分にもなっている。

残るはWindows Phoneか、IS12T使ってて気に入ってたんだがあれも7.8→8のアプデがキャンセルでサポートが3年ちょいで終わった上にその後は長いことおま国だったしな。

ということで新しい端末買う気も無いのでもう暫くはNexus5使うかなんだけど

という2択はどうしたもんかね。

とりあえずいくつかのカスROMは試してみた結果

しかしこの手のカスROMって細かい不具合がストレスで端末壁に投げつけたくなるだけだから金の力で解決(新端末購入)しようぜと、Android4系(Kitkat)をMOTOROLA PHOTON(ISW11M)やhtc Evo 3D(ISW12HT)に入れた時に悟ったはずなんだが。 もはや金のパワーは失われておるし仮にあっても欲しい端末が無い。

2017/04/27(Thu)

[Windows] Windows 7 のセキュリティアップデート統合済DVDを作成する (その2000)

ちょっと間が空いたけど 前回の続き、いつもの通り脱線しまくりでいつ本線に戻るのかそしてちゃんと最後まで書くかは知らん。

@Windows Vista以降のサービスパック及び修正パッチ

これまでのHotfix Packageに代わり、Microsoft Software Update Package(MSU)という新しい方法に切り替わりました。

拡張子.msu をダブルクリックすると修正パッチの適用がはじまりますが、これは実行可能形式というわけではなくwusa.exeつまり

と関連付けられているだけで、中身はただのCAB形式(Micorsoft Cabinet Format)のアーカイブです。

試しにWindows6.1-KB2454826-v2-x64.msuをexpandコマンドで伸長してみましょう。

D:\>mkdir KB2454826
D:\>expand -F:* Windows6.1-KB2454826-v2-x64.msu KB2454826
Microsoft (R) File Expansion Utility  Version 6.1.7600.16385
Copyright (c) Microsoft Corporation. All rights reserved.

...

ファイルの解凍が完了しました...
合計 4 ファイル

「解凍」なら「圧縮」じゃなくて「冷凍」じゃねちゅークッソ古いネタでキャッキャしたいご老体はfjへどうぞ。

ということで.msuの中に入ってたのは

  • Windows6.1-KB2454826-v2-x64-pkgProperties.txt … Windows Update メタデータ
  • Windows6.1-KB2454826-v2-x64.cab … パッケージ本体
  • Windows6.1-KB2454826-v2-x64.xml … 無人インストール応答ファイル
  • WSUSSCAN.cab … オフライン更新時のスキャン定義ファイル

という4つのファイルです。

@Windows Update メタデータ

このパッケージに関する情報が書かれたファイルです。

 ApplicabilityInfo="Windows 7.0 Client;Windows 7.0 Server Core;Windows 7.0 
 Embedded;Windows 7.0 Server;"
 Applies to="Windows 6.1"
 Build Date="2011/01/26"
 Company="Microsoft Corporation"
 File Version="2"
 Installation Type="FULL"
 Installer Engine="Component Based Servicing - WUSA.exe"
 Installer Version="6.0.0.0"
 KB Article Number="2454826"
 Language="ALL"
 Package Type="Update"
 Processor Architecture="amd64"
 Product Name="Windows 6.1"
 Support Link="http://support.microsoft.com?kbid=2454826"

という情報が書かれています。

このうち

  • Product Name … 製品名
  • KB Article Number … KB番号(その詳細についてはSupport LinkにあるURLを参照)
  • File Version … 改定番号
  • Processor Architecture … CPUアーキテクチャ
  • Language … 言語

は連結するとパッケージのファイル名になりますな。

<製品名>-<KB番号>-v<改定番号>-<CPUアーキテクチャ>-<言語>.msu

なお改定番号が1、言語がALLの場合はそれぞれファイル名では省略される命名規約っぽい。

また製品名と被る部分がありますが

  • ApplicabilityInfo … 適用対象となる(製品名より詳細な)OSとそのエディションの名称、サービスパックの有無など
  • Applies to … 適用対象のWindowsバージョン

という項目もあり、インストーラーがより厳密にチェックすることができます(それでも簡易チェックね、インストール時にはスキャン定義ファイルを使ってもっと厳密にやります)。

パッケージには用途に応じて

  • FeaturePack … 新機能
  • Foundation … Windowsの機能の有効化または無効化
  • Hotfix … 重大な更新
  • LanguagePack … 言語パック
  • LocalPack … 特定の地域だけに提供される機能
  • Product … エディション(Home{Basic,Premium}/Professional/Ultimate)それぞれ固有機能
  • SecurityUpdate … セキュリティの更新
  • ServicePack … サービスパック
  • Update … 更新

という分類があるのですが、これはPackage Typeとして記載されています。

そして最後はインストーラーについてです。

  • Installation Type="FULL"
  • Installer Engine="Component Based Servicing - WUSA.exe"
  • Installer Version="6.0.0.0"

Installer Engineには

など他にもありますが、ここではWUSAのバージョン6.0.0.0を使って「完全インストール(FULL)」を実施するという情報が書かれています。

Component Based Servicingとは何ぞやについてはまたいずれ。

@無人インストール応答ファイルとパッケージ本体

無人インストール応答ファイルとは何ぞやというと、これは元々Windows XPの時代から存在する

において、本来ならユーザーがインストーラーと対話型で選択や入力をしながら行っていく設定内容(例えばコンピューター名やシリアル番号など)を、事前に作ったunattend.xmlというファイルを食わせることで自動で設定するものです。

ですがWindows Vista以降はSysprepだけではなく

というパッケージインストーラーが使うインストールスクリプトとしても使われてるんですな。

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <servicing>
        <package action="install">
            <assemblyIdentity  name="Package_for_KB2813347" version="6.1.1.0" language="neutral" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35"/>
            <source location="%configsetroot%\Windows6.1-KB2813347-x86.CAB" />
        </package>
     </servicing>
</unattend>

はい、WSUAやMSIに続いてPkgmgrとかまた新しいパッケージインストーラーが出てきて混乱の極みですが、これらの関係はまた後日説明します。

この無人インストール応答ファイルの中でsource localtionとして指定されてる拡張子.cabなファイルですが、こいつはただのCAB形式ではなくて

と圧縮アーカイバとバイナリ差分パッチの掛け合わせになっております。未対応のツール(エクスプローラーの圧縮フォルダなど)でみると

  • _manifest_.cix
  • 0
  • 1

みたいな意味不明のファイルになってしまうので注意、なんでわざわざバイナリ差分なのかはまたいずれ説明します。

このIPDについてはさっき使ったばっかりのexpandコマンドが対応済(Vista以降)なので、この.cabもそれで展開してみましょう。

D:\>mkdir KB2454826\expaned
D:\>expand -F:* expand -F:* Windows6.1-KB2454826-v2-x64.cab KB2454826\expaned
Microsoft (R) File Expansion Utility  Version 6.1.7600.16385
Copyright (c) Microsoft Corporation. All rights reserved.

...

ファイルの解凍が完了しました...
合計 239 ファイル

大量のフォルダとファイルが展開されますが、中身は

  • update.mum
  • update.cat
  • package_1_for_kb2454826~31bf3856ad364e35~amd64~~6.1.2.0.mum
  • package_1_for_kb2454826~31bf3856ad364e35~amd64~~6.1.2.0.cat

という同名ペア(拡張子.mum + 拡張子.cat)がまずひとつ。

そして

  • amd64_microsoft-windows-activexproxy_31bf3856ad364e35_6.1.7600.20743_none_6eb606b01cfa520a
  • amd64_microsoft-windows-activexproxy_31bf3856ad364e35_6.1.7600.20743_none_6eb606b01cfa520a.manifest

というやはり同名ペア(フォルダ + 拡張子.manifest)がもう一つ。

これらが何なのかはまた次回改めて説明します。

@オフライン更新時のスキャン定義ファイル

Windows Updateを実施した場合はオンラインでWindows Updateサーバと通信して更新ファイルの検索を行うんですが、インターネットにつながってない環境でも

を使うと必要なパッチの検索ができます、その為のデータベースで本題とあまり関係ないので説明はここまで。

@次回

飽きてきた、パッケージ本体の中身について引き続き書く予定。

2017/04/29(Sat)

[旅行] 厚木基地 日米親善春まつり(NAF Atsugi Spring Festival)

去年も行きそびれたのだけど、今年も入場に必要な

を用意するのを忘れててダメだった、まぁ海軍機もEA-6が退役でもはやF/A-18しかないし *1まあ騒ぐほどでもないか(エリア88脳)…

写真は2013年に撮影したもの。

ところで厚木基地へのアクセス方法ってNAFの公式Facebookもなんだけど「飛行場正門」で下車ってやつがネットの検索結果で大多数なのよね。

なのでこれを信じて、以下のアクセス手段を選ぶ人が多いかと思われるんだけど。

でもこの日ばかりはこのルート使うと絶対後悔するので注意ね、というのも

というトラップがあるんですよな。

例年だと一番混雑する時間帯の最後尾は光陵運動公園をグルっと一周しても足りずに綾北中学校の前あたりでまた折り返したりしてます。

なのではじめっから光陵運動公園を目指して

で行くといいです、20分に1本あるし知られていないのか長後駅発とか全然空いてるしね。

今年は列の長さはいくぶんマシだったぽいですが、その場合は上深谷からもうひと停留所だけ飛行場正門寄りの「観音入口」で降りればおk。

そういえば写真撮るのに何とかのひとつ覚えで「白い大砲」みたいな超望遠レンズつけた一眼で来場するオッサンが多いんですが

のでむしろフルサイズ換算17-35mmくらいの広角レンズ一本あれば事足りるんだよね…

というか一昨年行った時はどっかの団体客のジジイ連中が

という世にも醜い光景をみたゾ、やっぱりコンデジより上のサイズのカメラは免許制にした方がいいと思う。

*1:前は海軍の方がいろんな機体があって行くなら厚木だったんだけど、最近は空軍の方がまだ種類多いので以下略
*2:数年前からF/A-18FやE-2Cが離陸をみせたりしますが「通常の飛行訓練(棒)」という建前らしいのでド派手な機動飛行は(ヾノ・∀・`)ナイナイありません。

2017/04/30(Sun)

[NetBSD] Let's Encrypt(certbot + dehydrated)で遊んでる程度でも地雷を踏みぬく素晴らしいユーザランド

@昨今はブラウザがHTTPだと安全でない安全でないうるさいので…

つーことでしばらく前にこのチラシの裏にも証明書入れたんですが、証明書に金かけられないので無料の

を使ってたんですが、こいつも Chromeやら MozillaにBANされる雑魚だったようで慌てて

に変更するハメに。

@certbotがまずクラッシュ

StartSSLの期限切れでrenewしたらこの事態になってることに気づいたのもあって、時間も無いので深く調べずに公式がお勧めしてる

をpkgsrcから導入したんですが、こいつが

# certbot-auto certonly --standalone -d ドメイン

を実行しても使用言語のPythonがオレオレN6上でバグってんのかcore吐いて死んでくれやがります、うーんこの。

障害原因を調べようにもやたらと牛刀割鶏な作りだし--standaloneがクラッシュするって事はPython本体のHTTPServerクラスのdebugになりかねんのでめんどくさい、また来世で。

とりあえず深追いしたくないのでnginxの設定に

location /.well-known/acme-challenge/ {
    alias <砂場>;
}

を追加して

# certbot-auto certonly --webroot -w <砂場> -d <ドメイン>

を実行して別の方法で導入は済ませた。

@dehydratedも動かねぇ

とはいえ、チラシの裏はディスク容量も無いしもっと軽量なやつがええなってことで、Bashだけで書かれた(うわBashかよ…)

に切り替えたんだけど、こっちもpkgsrcから突っ込んだところ

# dehydrated -register --accept-terms

の実行中にsed(1)が

sed: RE error: invalid argument to regex routine

とおっしゃられる、ハハハこやつめ(ブチ切れ)。

問題のコードはこの部分やね。

262   # Get public components from private key and calculate thumbprint
263   pubExponent64="$(printf '%x' "$(openssl rsa -in "${ACCOUNT_KEY}" -noout -text | awk '/publicExponent/ {print $2}')" | hex2bin | urlbase64)"

パイプで繋いでるhex2bin及びurlbase64という2つのシェル関数の中でsedが使われてます

320 # Encode data as url-safe formatted base64
321 urlbase64() {
322   # urlbase64: base64 encoded string with '+' replaced with '-' and '/' replaced with '_'
323   openssl base64 -e | tr -d '\n\r' | _sed -e 's:=*$::g' -e 'y:+/:-_:'
324 }
325
326 # Convert hex string to binary data
327 hex2bin() {
328   # Remove spaces, add leading zero, escape as hex string and parse with printf
329   printf -- "$(cat | _sed -e 's/[[:space:]]//g' -e 's/^(.(.{2})*)$/0\1/' -e 's/(.{2})/\\x\1/g')"
330 }

コマンドそのものは_sedシェル関数でラップされてますがこれは

300 # Different sed version for different os types...
301 _sed() {
302   if [[ "${OSTYPE}" = "Linux" ]]; then
303     sed -r "${@}"
304   else
304     sed -E "${@}"
305   fi
306 }

Linuxの場合(つまりGNU sedと言いたいのだろう)であれば-rオプション、それ以外(つまりBSD sed以下略)なら-Eを使うようになってます。

unameでsedのチェックってクッソ雑やなーディストリとかによって差異あるやろとか、そもそも最近のGNU sedなら

	-E
	-r
	--regexp-extended
		Use extended regular expressions rather than basic regular expressions. Extended regexps are those that egrep accepts; they can be clearer
		because they usually have fewer backslashes. Historically this was a GNU extension, but the -E extension has since been added to the
		POSIX standard (http://austingroupbugs.net/view.php?id=528), so use -E for portability. GNU sed has accepted -E as an undocumented
		option for years, and *BSD seds have accepted -E for years as well, but scripts that use -E might not port to other older systems. See
		Extended regular expressions.

と-Eも実装されてる(-rと等価)ので意味ないよね…

@とりあえず原因は特定

まぁ心のマサカリは封印しつつ今起きてる障害の最小ケースを作成すると、Base64の末尾につくパディング目的の「=」を除去する目的の正規表現である

$ echo -n 'A' | sed -E -e 's/=*$//g'
sed: RE error: invalid argument to regex routine

を実行するとこでエラー出てることがわかりまんた。

  • echoに-nをつけない(つまり最後に改行がある)時はエラーにならない
  • 入力の最後に'='がある(つまり正規表現で置換が実行される)時はエラーにならない

ちゅー挙動、これどう考えても正規表現エンジンのバグよね。

まぁそもそも末尾のパディング除去なら

$ echo -n 'A' | sed -E -e 's/=+$//'

と「*(0個以上)」でなく「+(1個以上)」にして、g(最初の1つだけでなく全て検索)も要らないよなと思うんだけど、これだとエラー出ない。

つーことで相変わらずpkgsrcを6.1でテストしてる人間がおらんことが証明されてしまった、つか誰も騒いでないなら7.1とかでは直ってるんだろうと思ったけど

$ echo -n 'A' | sed -E -e 's/=*$//g' | od -x
0000000     0a41
0000001

バグ直ってるように見えて実は勝手に改行コード(0xA)が付与される新たなバグが埋められてて草不可避、サイレントに壊れてるってよりタチが悪いんですが。

ちなみにFreeBSD(11.0)とかOpenBSD(6.1)は問題ないもよう。

$ echo -n 'A' | sed -E -e 's/=*$//g' | od -x
0000000     0041
0000001

@暫定回避策

ふつうBSD sedはlibcのregex(3)に正規表現は丸投げなのでそっちのバグを修正しないとならんけど、今日のところは暫定でGNU sed(gsed)を呼ぶようにして回避でおしまい。

--- dehydrated.orig     2017-04-30 15:10:33.000000000 +0000
+++ dehydrated  2017-04-30 15:14:45.000000000 +0000
@@ -301,6 +301,8 @@ init_system() {
 _sed() {
   if [[ "${OSTYPE}" = "Linux" ]]; then
     sed -r "${@}"
+  elif [[ "${OSTYPE}" = "NetBSD" ]]; then
+    gsed -r "${@}"
   else
     sed -E "${@}"
   fi

今度こそ正しいunameの使い方である(ひどい)

さっきも書いたように「*」でなく「+」を使う方法もあるけど。

--- dehydrated.orig     2017-04-30 15:10:33.000000000 +0000
+++ dehydrated  2017-04-30 16:13:01.000000000 +0000
@@ -320,7 +320,7 @@ clean_json() {
 # Encode data as url-safe formatted base64
 urlbase64() {
   # urlbase64: base64 encoded string with '+' replaced with '-' and '/' replaced with '_'
-  openssl base64 -e | tr -d '\n\r' | _sed -e 's:=*$::g' -e 'y:+/:-_:'
+  openssl base64 -e | tr -d '\n\r' | _sed -e 's:=+$::' -e 'y:+/:-_:'
 }

 # Convert hex string to binary data

でも、他にもバグあるかもだし一番テストされてるであろうGNU sedに寄せるのが安全よね。