タイトル/名前 | 更新者 | 更新日 |
---|---|---|
技術/Security/PKI,SSL,TLS/メモ02_OpenSSLとRSA | msakamoto-sf | 2013-07-27 18:52:23 |
技術/Security/PKI,SSL,TLS/メモ01_拡張子の迷宮(pem,der,crt,cer,csr,...) | msakamoto-sf | 2013-07-27 18:52:15 |
技術/UNIX/od, hexdump, xxd : 16進数 or 2進数ダンプ | msakamoto-sf | 2013-07-27 18:47:09 |
日記/2013/07/27/調べ物 : Node.js | msakamoto-sf | 2013-07-27 17:49:41 |
日記/2013/07/27/調べ物:Javaで書かれたWikiエンジン | msakamoto-sf | 2013-07-27 17:44:01 |
技術/OSSライセンス/"Stack Overflow"上のソースコードスニペット | msakamoto-sf | 2013-07-27 11:15:02 |
技術/UNIX/hostname | msakamoto-sf | 2013-07-27 10:40:13 |
Java/ClassLoaderの分割 : kamranzafar/JCL | msakamoto-sf | 2013-07-21 11:40:58 |
Groovy/Gradle/Eclipseとの連携/SpringのEclipsePlugin使用メモ | msakamoto-sf | 2013-07-15 12:07:25 |
Groovy/Maven/Eclipse + GGTS使用時のメモ | msakamoto-sf | 2013-07-15 11:52:51 |
OpenSSLでRSA秘密鍵・公開鍵を作成し、署名したり署名を検証したりしてみました。
> openssl version OpenSSL 0.9.8h 28 May 2008
古い・・・。大分前に以下のURLからインストールしたOpenSSL使ってます。
genrsaコマンドでRSAに使う秘密鍵を生成する。
> openssl genrsa Loading 'screen' into random state - done Generating RSA private key, 512 bit long modulus ........++++++++++++ ..++++++++++++ unable to write 'random state' e is 65537 (0x10001) -----BEGIN RSA PRIVATE KEY----- MIIBOwIBAAJBAOCBzlG9MrPdUXWgGIMN8LooK4UAiT28aEZ69flortYuzzwXb47q WTeQkrTVnbJzopYRRLDswWbfNukAA9hwSbcCAwEAAQJAGpcFKqUv5iGmTjoh7ROv mTy8usnvd0JjT0Ws8Fc3reIwlrNX4ahsL9GqgFY7YMbZIeaXqAagXopZvpg5fuwo cQIhAPXu0MKxH4nZYTBDeF4Dx2Iec8JcD8HOly7hZpWnWY29AiEA6bJ28MZMsfDT BtIsP4RiLddV9Fws/2yoEC2HWpAm6oMCIQCoRPuvipNitUqLRE7SPNGqL93SiTz6 xUip+e0/zh43HQIgHT9Sl2uZ6aMkJfRjyUc+KlKK1Vw73XOxzOSFzhXAaRUCIQDy lMdy/X4wxbDD6wfA0RCgqGGYiGooblFJucQREIhATA== -----END RSA PRIVATE KEY-----
ビット数を指定する場合は最後に引数で指定:
> openssl genrsa 1024
ファイルに出力する:
> openssl genrsa -out testrsa01_sec.pem
AES256(CBC)で暗号化する:
> openssl genrsa -aes256 -out testrsa01_sec_aes256.pem Loading 'screen' into random state - done Generating RSA private key, 512 bit long modulus .......++++++++++++ ..++++++++++++ unable to write 'random state' e is 65537 (0x10001) Enter pass phrase for testrsa01_sec_aes256.pem:(パスフレーズ入力) Verifying - Enter pass phrase for testrsa01_sec_aes256.pem:(パスフレーズ入力)
暗号化すると"Proc-Type"と"DEK-Info"が追加されました:
-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC,189... c7f5hYcyY6c95ay73R8udIaPOBWGmukmYI46glvFOtUA2pnS2LYpiIAuvrk9obZP ... -----END RSA PRIVATE KEY-----
RSAの暗号鍵から公開鍵を生成するのに使う。署名や暗号化処理にはrsautlコマンドを使う。
暗号化していない秘密鍵から:
> openssl rsa -pubout < testrsa01_sec.pem > testrsa01_pub.pem writing RSA key
暗号化した秘密鍵から:
> openssl rsa -pubout < testrsa01_sec_aes256.pem > testrsa01_pub_aes256.pem Enter pass phrase: writing RSA key
デフォルトの出力形式はPEM形式となっている。
秘密鍵の暗号化を解除する:
> openssl rsa < testrsa01_sec_aes256.pem > testrsa01_sec_aes256_nopass.pem
暗号化されていない秘密鍵を暗号化する:
> openssl rsa -aes256 < testrsa01_sec.pem writing RSA key Enter PEM pass phrase:(パスフレーズ入力) Verifying - Enter PEM pass phrase:(パスフレーズ入力) -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC,6EDEE202C1D95242C7541CB66448CE74 vUPpCqLnGrrardKlcfRZVCIgRBw1bCnxchozP1A19Zr0bt9IhvmkYch3Cec7xSbO jwMGF/ACeYtVHCdppuEcf6wKlpSiZivyfy04fvDZ4KWZltkNN6YsKtbUEJ0A7uwJ iqUEccD6/sZelxylDzjkPsxoXO7xVWk/rW8EUFcI3l/Zf6uk9L3E1CRR3M8DUY1U zqVfCWFrLo6sP6xJ6cMIh6w8b6EPMS/3ITMdF3ek+x77Cip4KZgAX0CcmdZpkjwy EmSf9LWyAbDOVIjqJTAeOAG+JJgjZ8WDueCLbSzgBTUBFnA4qVwqTboMcSxYjgTF ZI2vefASaV32lMMqE9Gv6HdibTlprqdgDVdy/GoPpxsShMKsOQKKgY2aumZb1pfL 13Meo2yhuGxpQm1Zim3+vjU5AJr86M8lBzzomiESwGQ= -----END RSA PRIVATE KEY-----
署名や暗号化処理を行う。暗号化された秘密鍵を使っている場合、秘密鍵を使う"-sign", "-encrypt"で暗号化を解くためのパスフレーズの入力を求められる。"rsaコマンド"の項で作成した testrsa01_sec.pem, testrsa01_pub.pem を使って以下のファイルに対して練習してみる。
plain.txt:
abcdefghijklmn
なお、"-keyform"を指定しない場合の鍵ファイルのフォーマットはPEM形式。
署名:"-sign" + "-inkey 秘密鍵ファイル"
> openssl rsautl -sign -in plain.txt -inkey testrsa01_sec.pem -out sign.bin Loading 'screen' into random state - done
sign.binはバイナリファイル。
秘密鍵による署名の検証:"-verify" + "-inkey 秘密鍵ファイル"
> openssl rsautl -verify -in sign.bin -inkey testrsa01_sec.pem Loading 'screen' into random state - done abcdefghijklmn
※元のファイル内容についてファイルに保存したい場合は "-out 出力ファイル名" を追加。
公開鍵による署名の検証:"-verify" + "-inkey 公開鍵ファイル" + "-pubin"
> openssl rsautl -verify -in sign.bin -inkey testrsa01_pub.pem -pubin Loading 'screen' into random state - done abcdefghijklmn
公開鍵ファイルを"-inkey"で指定しつつ、"-pubin"を指定しない場合、"-inkey"が秘密鍵として扱われエラーとなる。
> openssl rsautl -verify -in sign.bin -inkey testrsa01_pub.pem Loading 'screen' into random state - done unable to load Private Key
公開鍵で暗号化:"-encrypt" + "-inkey 公開鍵ファイル" + "-pubin"
> openssl rsautl -encrypt -in plain.txt -inkey testrsa01_pub.pem -pubin -out plain_enc.txt
暗号化されたデータはバイナリ形式。"-pubin"を指定しない場合は秘密鍵として扱われエラーとなる。
秘密鍵で暗号化:"-encrypt" + "-inkey 秘密鍵ファイル"
> openssl rsautl -encrypt -in plain.txt -inkey testrsa01_sec.pem -out plain_enc2.txt
秘密鍵でも暗号化できるが、復号化には公開鍵ではなく秘密鍵が必要となる。
秘密鍵で復号化:"-decrypt" + "-inkey 秘密鍵ファイル"
> openssl rsautl -decrypt -in plain_enc.txt -inkey testrsa01_sec.pem Loading 'screen' into random state - done abcdefghijklmn
OpenSSLやPKI周りを調べていると、拡張子が色々出てきて混乱したので整理しました。
特にX509証明書関連については、以下のWikiページを参考にしています。
Base64符号化を使ったデータフォーマット。データのenvelopeとしてのフォーマットであり、データの中身は特に問わない。そのため証明書や鍵データ等幅広く使われている。OpenSSLでもサポートされており、様々なオブジェクトデータで"-inform", "-outform"オプションに指定可能。
元々E-Mailの暗号化や認証システムとしてRFC 1421 - 1424で提案されており、フォーマットはその中に包含されていた。フォーマットについては広く使われるようになったが、暗号化や認証システムについてはPKIに取って代わられたようだ。
バイナリ形式のデータ形式で、OpenSSLでもサポートされている。
元を辿ればASN.1 (Abstract Syntax Notation One) という抽象構文を表現するためのフォーマットの一つ。ASN.1自体はあくまでも抽象構文を表現する表記法(Notation)であり、データ構造の定義を担う。これを実際のバイナリフォーマットとして表現するためのフォーマットの一つがDERであり、他にもBERやCERなどあり、この話題や文脈で"~ER"ときたらほぼ"Encoding Rules"と考えてよいだろう。
乱暴にまとめるとASN.1はC言語の文法を表現するBNF記法に相当し、BER/DER/CERは文法を解析してアセンブラに変換するコンパイラに相当すると考えてよい。
CA(認証局)に提出する証明書要求データ。ファイルフォーマットと関連付いておらず、PEM形式なのかDER形式なのかは内容を確認しないと判断できない。
X509証明書を保存したファイルの場合、
-----BEGIN CERTIFICATE-----
で始まり、
-----END CERTIFICATE-----
で終わるテキストファイルであればPEM形式とみてほぼ間違いない。
テキスト形式ではなくバイナリデータであればDER形式の可能性が高いが、X509そのままではなく、PKCS#7形式の可能性もある。
X509そのままの例:
> openssl asn1parse -inform DER < veri_ie_der.cer 0:d=0 hl=4 l=1577 cons: SEQUENCE 4:d=1 hl=4 l=1297 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 16 prim: INTEGER :641BE820CE020813F32D4D2D95D67E67 31:d=2 hl=2 l= 13 cons: SEQUENCE 33:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption 44:d=3 hl=2 l= 0 prim: NULL 46:d=2 hl=3 l= 202 cons: SEQUENCE 49:d=3 hl=2 l= 11 cons: SET 51:d=4 hl=2 l= 9 cons: SEQUENCE ...
PKCS#7形式の例:
> openssl asn1parse -inform DER < C:\Users\FengJing\Desktop\veri_pkcs7.p7b 0:d=0 hl=4 l=2863 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData ^^^^^^^^^^^^^^^^^ 15:d=1 hl=4 l=2848 cons: cont [ 0 ] ...
実験としてIE9とFirefox9で "VeriSign Class 3 International Server CA - G3" という中間証明書をエクスポートしてみる。
まずIE9の「インターネットオプション」メニュー→「コンテンツ」タブ→「証明書」ボタン→「中間証明機関」タブで "VeriSign Class 3 International Server CA - G3" を選択、「詳細」タブで「ファイルにコピー」ボタンをクリックすると「証明書のエクスポート ウィザード」が開始される。
ウィザードの途中でエクスポートファイルの形式を選択できる。IE9で今回の証明書の場合はDER, PEM(="Base 64 encoded X.509"), PKCS#7 が選択できる。
ここでは"Base 64 encoded X.509"を選択し適当なファイル名で保存する。IE9の場合、デフォルトの拡張子は".cer"として保存された。
続いてFirefox9の「Tools」メニュー→「Options」メニュー→「Advanced」タブ→「View Certificates」ボタン→「Authorities」タブで "VeriSign Class 3 International Server CA - G3" を選択、「Export」ボタンをクリックすると保存ダイアログが表示される。
ここでは "X.509 Certificate (PEM)" 形式で保存する。Firefox9の場合、デフォルトの拡張子は".crt"として保存された。
IE9, Firefox9のそれぞれでPEM形式で保存したが、内容を確認すると全く同一の内容であることが確認される。
またFirefox9でエクスポートするときに "X.509 Certificate with chain (PEM)" 形式で保存すると、以下のように上位の認証局("VeriSign Class 3 Public Primary Certification Authority - G5")の証明書がPEM形式で追加されている。
-----BEGIN CERTIFICATE----- MIIGKTCCBRGgAwIBAgIQZBvoIM4CCBPzLU0tldZ+ZzANBgkqhkiG9w0BAQUFADCB (... "VeriSign Class 3 International Server CA - G3" の証明書 ...) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE0zCCA7ugAwIBAgIQGNrRniZ96LtKIVjNzGs7SjANBgkqhkiG9w0BAQUFADCB ... ("VeriSign Class 3 Public Primary Certification Authority - G5" の証明書) ... -----END CERTIFICATE-----
続いてIE9で上と同じ証明書を"veri_ie_der.cer"という名前でDER形式で保存し、opensslコマンドでテキスト形式に変換してみる。
> openssl x509 -inform DER -in veri_ie_der.cer -text > veri_ie_der.txt
更にPEM形式で保存したいファイルについても同様にテキスト形式で保存してみる。
> openssl x509 -inform PEM -in C:\Users\FengJing\Desktop\veri_ie_pem.cer -text > veri_ie_pem.txt
当然であるが、2つのファイルの内容は完全に一致している。またテキスト形式では末尾にPEM形式でのデータが記載されている。
使うたびにググってるので、いい加減、よく使うパターンについてメモ。
16進数(od, hexdump, xxd)と2進数(xxd)ダンプ出力の、よく使うコマンド例のまとめ。
(unix上でのバイナリファイルの編集については 技術/vim/メモ6, バイナリデータの編集 とか参照。)
-v : 直前と同じ内容を持つ行も表示する。事実上、必須。 -Ax : 基数を16進数に。 -t : GNU od : -tx1z : 1バイトずつ16進数で、対応する文字を行末にまとめて表示。 BSD, Solaris : -tx1c : 1バイトずつ16進数で、対応する文字を次の行に表示。
$ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | od -Ax -tx1z 000000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 >abcdefghijklmnop< * 000020 71 72 73 74 75 0a >qrstu.< 000026 $ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | od -Ax -tx1z -v 000000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 >abcdefghijklmnop< 000010 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 >abcdefghijklmnop< 000020 71 72 73 74 75 0a >qrstu.< 000026 $ echo "abcdefghijklmnopqrstu" | od -v -Ax -tx1c 000000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 a b c d e f g h i j k l m n o p 000010 71 72 73 74 75 0a q r s t u \n 000016
from http://linuxjm.sourceforge.jp/html/util-linux/man1/hexdump.1.html :
-C : 標準的な 16進数 + ASCII での表示。 -v : odの"-v"と似た機能。事実上、必須。
$ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | hexdump -C 00000000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 |abcdefghijklmnop| * 00000020 71 72 73 74 75 0a |qrstu.| 00000026 $ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | hexdump -C -v 00000000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 |abcdefghijklmnop| 00000010 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 |abcdefghijklmnop| 00000020 71 72 73 74 75 0a |qrstu.| 00000026
-g N : Nバイトごとにグルーピング。1バイトずつ見たいなら "-g 1" -b : 2進数表示
$ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | xxd -g 1 0000000: 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 abcdefghijklmnop 0000010: 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 abcdefghijklmnop 0000020: 71 72 73 74 75 0a qrstu. $ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | xxd -g 2 0000000: 6162 6364 6566 6768 696a 6b6c 6d6e 6f70 abcdefghijklmnop 0000010: 6162 6364 6566 6768 696a 6b6c 6d6e 6f70 abcdefghijklmnop 0000020: 7172 7374 750a qrstu. $ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | xxd -g 1 -b 0000000: 01100001 01100010 01100011 01100100 01100101 01100110 abcdef 0000006: 01100111 01101000 01101001 01101010 01101011 01101100 ghijkl 000000c: 01101101 01101110 01101111 01110000 01100001 01100010 mnopab 0000012: 01100011 01100100 01100101 01100110 01100111 01101000 cdefgh 0000018: 01101001 01101010 01101011 01101100 01101101 01101110 ijklmn 000001e: 01101111 01110000 01110001 01110010 01110011 01110100 opqrst 0000024: 01110101 00001010 u.
参考:
いい加減勉強しないとヤバイかなぁ・・・
WindowsへのNode.jsのインストール、というか"nvm"のインストール:
・・・なんでPythonが必要なのか?
会社内でのみ利用する業務アプリケーションでLGPL, EPLは使えるか?
→多分・・・大丈夫な気がするんだが・・・。
ライブラリ自体を変更しない限りは、そのライブラリとリンクしたソフトウェアのソースコードについては公開義務は生じない、という認識。仮にその認識が間違っていたとしても、社内でのみdeployし、利用者も社内のみで、利用者=社員から求められればソースコードは開示出来る状況であればGPLにすら違反していないのでは?
バイナリだけ配布する場合が問題となるか。
"Stack Overflow" ( http://stackoverflow.com/ ) は最近(2011-2013)、特にお世話になることが多いITエンジニア向けのQAサイトで、質問や回答の中にサンプルコードが記載されていることも多々あります。
これらのソースコードスニペットのライセンスってどうなってるの?というところですが、既にStack Overflowでも話題になっていたようです。
結論から言うと、"Stack Overflow"のlegalページで "Creative Commons Attribution Share Alike license" が適用されるということが書いてありました。
SO上に投稿されたコンテンツは上記のCCライセンスが適用されるので、使う側としては大変助かります。
投稿する側として気をつけなければならないのは、プロプライエタリなソースコードを抜粋などで投稿してしまうとライセンスを侵害してしまうことになりかねないので、非常に注意が必要というところでしょうか。
ただ、自分もソフトウェアやコンテンツに関する著作権・ライセンスの専門家ではありませんので、上記理解で問題ないと断言できる状態ではありません。
よほど単純なサンプルコードでない限りは、自分の手元で検証した上で、自分なりにスクラッチで作りなおしたのを使う方が安全かもしれません。
あまり使っててトラブルになるようなコマンドではないが・・・
ただし、rootユーザで誤って
# hostname www.example.com
とすると、ホスト名を変更してしまうので注意が必要か。
また、ドメイン部分を削ったホスト名を表示してくれる(Linux, BSD) "-s" オプションだが、一部のSolarisではホスト名変更オプションになっていたことがあるらしく、うっかり
# hostname -s
とかするとホスト名が空文字・・・になるのかな・・・とにかく、変更されてしまう場合が在ったらしい。
その場合、
HOST=`hostname | cut -d. -f1`
のようにしてホスト名を取り出している、という技法を紹介してるblogがあった。
なおSolaris 10, 11ともに "-s" オプションはなくて単にホスト名を指定してればセット、引数が無ければホスト名を表示、というだけのシンプルなコマンドになっている。上記の話は、もうちょっと一昔前のSolarisの話かもしれない。特にどのバージョンで、というのも記載が無かったきがする。
ClassLoaderを分割したい場合のメモ。
Jarファイルをロードするカスタムクラスローダ。
https://github.com/kamranzafar/JCL
特色としては、単にクラスローダを分割するだけでなく、分割したクラスローダ間でのクラスキャストに対応していること。
Javaでは異なるクラスローダでロードされたClassは別物として扱われるため、以下の様なケースでは一般にClassCastExceptionが発生する。
JCLでは、これを解決するために二種類の方式を提供している。
詳しくはJCLのソースコード、"org.xeustechnologies.jcl.proxy"パッケージを参照。
おおよその動作確認環境:
JDK 1.7 Eclipse 4.2 Juno SR2 Gradle IDE(=eclipse-integration-gradle) 3.1.0.xxxxx
使用時の細かいメモ。
他にも、未解決のIssueは以下で見れます。マルチプロジェクト構成だったり、依存関係が複雑だったりすると色々トラブルが発生しているようです。Eclipse WTPとの連携もまだまだこれからでしょうね・・・。MavenのEclipseプラグインであるm2eがようやくm2e-wtpとしてKeplerで安定してきたばかりですし・・・。
スクリーンショットとか取ってないので分かりづらいんですが、最初Gradle IDEの3.1.0.xxxxxxを入れました。他にもSpringのGGTSとか入れてましたので、その辺りで何かおかしくなったと思うんですが、"Help" -> "About Eclipse" -> "Installation Details" で見ると、なぜか
Gradle IDE Gradle Tooling API Gradle Tooling API
というように、"Gradle Tooling API"が2つ、しかも一方は"Gradle IDE"の下に、もう一方はトップレベルに入ってるんです。バージョン番号は一緒。
で、この状態でアップデートしようとすると
Cannot complete the install because of a conflicting dependency. Software being installed: Gradle IDE 3.3.0.201307040643-RELEASE (org.springsource.ide.eclipse.gradle.feature.feature.group 3.3.0.201307040643-RELEASE) Software currently installed: Gradle Tooling Api 3.1.0.201210040512-RELEASE (org.gradle.toolingapi.feature.feature.group 3.1.0.201210040512-RELEASE) Only one of the following can be installed at once: SpringSource Tool Suite Gradle Integration (Core) 3.3.0.201307040643-RELEASE (org.springsource.ide.eclipse.gradle.core 3.3.0.201307040643-RELEASE) SpringSource Tool Suite Gradle Integration (Core) 3.1.0.201210040512-RELEASE (org.springsource.ide.eclipse.gradle.core 3.1.0.201210040512-RELEASE) Cannot satisfy dependency: From: Gradle Tooling Api 3.1.0.201210040512-RELEASE (org.gradle.toolingapi.feature.feature.group 3.1.0.201210040512-RELEASE) To: org.springsource.ide.eclipse.gradle.core [3.1.0.201210040512-RELEASE] Cannot satisfy dependency: From: Gradle IDE 3.3.0.201307040643-RELEASE (org.springsource.ide.eclipse.gradle.feature.feature.group 3.3.0.201307040643-RELEASE) To: org.springsource.ide.eclipse.gradle.core [3.3.0.201307040643-RELEASE]
というエラーになるんですね。多分Gradle Tooling APIが2つあるために依存関係がおかしくなってると思うのですが・・・。
試しにトップレベルの"Gradle Tooling API"をアンインストールして、その後、"Gradle IDE"をアップデートしたら成功しました。
ただ、"Gradle IDE"を3.3にアップデートしたら"Gradle Tooling API"が今度は表示されなくなったんですよね・・・。でもGradleプロジェクトは正常に操作できてて・・・謎・・・。
もしかしたら何かの表紙にトラブルになるかもと考えると多少心配ですが、まぁ最悪クリーンインストールすれば良いので考えないでおきます。
Gralde IDEのインストール方法が悪かったんですかね?GGTSでくっついてくるSTS Dashboardから / Market Place から / UpdateSite登録して手動で / のどれか忘れたのですが・・・。(ただ、少なくともUpdate Site手動登録はしてない。)
Eclipse + GGTS(Groovy/Grails Tool Suite) でMaven仕立てのGroovyプロジェクトを使う時のメモ。
・嵌ったところ: