Perhaps it will only be trusted (for me) if Steve re-signs it after I signed his key... makes sense. We'll see for the next release... (so sign those keys now?)
On Fri, Aug 14, 2015 at 8:17 AM, Shazron <shaz...@gmail.com> wrote: > I think it's a web of trust thing > http://security.stackexchange.com/questions/6841/ways-to-sign-gpg-public-key-so-it-is-trusted > I signed Steve's key, but you won't trust it unless you sign my key, and > so on.. there must be a link of trust. But then I signed his key and I > still get this warning, so... > > On Fri, Aug 14, 2015 at 8:13 AM, Shazron <shaz...@gmail.com> wrote: > >> Not sure. Try GPG Keychain -> Key -> Update Key From Server (after >> selecting Steve's key) >> >> On Fri, Aug 14, 2015 at 7:30 AM, Carlos Santana <csantan...@gmail.com> >> wrote: >> >>> So I need to re-import all the pgp keys? >>> >>> I just did the two import commands here: >>> >>> https://github.com/apache/cordova-coho/blob/master/docs/setting-up-gpg.md#importing-pmc-members-pgp-keys >>> >>> Do I need to do it again? >>> >>> On Thu, Aug 13, 2015 at 7:17 PM Shazron <shaz...@gmail.com> wrote: >>> >>> > I think someone else on the team needs to key sign Steve's key (use GPG >>> > Keychain). I just did for both his apache and gmail keys. >>> > >>> > On Fri, Aug 14, 2015 at 4:55 AM, Homer, Tony <tony.ho...@intel.com> >>> wrote: >>> > >>> > > Thanks for replying Steve - I see what you mean about dependencies, >>> > hadn't >>> > > thought about that. >>> > > >>> > > When I did `coho verify-archive` I got "gpg: WARNING: This key is not >>> > > certified with a trusted signature!". >>> > > I guess this is ok, but is there any way to address the warning? >>> > > >>> > > >>> > > On 8/13/15, 2:47 PM, "Steven Gill" <stevengil...@gmail.com> wrote: >>> > > >>> > > >Audit license headers is the important one. >>> > > > >>> > > >At the end of the day, we aren't shipping any of our dependencies. >>> They >>> > > >are >>> > > >all downloaded by our users. We can contact module authors who don't >>> > have >>> > > >license listed to get them to list one. >>> > > > >>> > > >-Steve >>> > > > >>> > > >On Thu, Aug 13, 2015 at 5:40 AM, Homer, Tony <tony.ho...@intel.com> >>> > > wrote: >>> > > > >>> > > >> I'm trying to validate the tools release. >>> > > >> I'm following the instructions[1], but I haven't used coho before >>> and >>> > am >>> > > >> not sure about the results. >>> > > >> >>> > > >> `coho audit-license-headers -r js -r lib -r cli -r plugman` >>> > > >> The doc warns that audit-license-headers has false positives, so >>> I'm >>> > > >> ignoring the following results: >>> > > >> ./appveyor.yml >>> > > >> ./tasks/vendor/commonjs-tests/* >>> > > >> ./tasks/vendor/jasmine/* >>> > > >> ./spec-cordova/* >>> > > >> ./spec-plugman/* >>> > > >> ./src/plugman/help.txt >>> > > >> Are these are all false positives? >>> > > >> If yes, I think the audit-license-headers results are ok. >>> > > >> >>> > > >> `coho check-license -r tools` >>> > > >> I got a lot of results so I started adding what I think are false >>> > > >> positives to the license filter: >>> > > >> "ISC","Public Domain","WTFPL","ASF","Unlicense","Artistic-2.0" >>> > > >> I also updated to nlf 1.3.2 in order to get nicer output and a >>> fix for >>> > > >>the >>> > > >> single license under licenses bug [2]. >>> > > >> I still get 88 results for packages with no license entry in >>> > > >>package.json. >>> > > >> (plus xmldom, which has a syntax error in the license entry but >>> has an >>> > > >> Apache-compatible license) >>> > > >> >>> > > >> Are "ISC","Public >>> Domain","WTFPL","ASF","Unlicense","Artistic-2.0" all >>> > > >> Apache-compatible? >>> > > >> Are packages with no license entry ok - any additonal action >>> required? >>> > > >> Should I submit a PR to add the additional license strings to the >>> > filter >>> > > >> and update nlf? >>> > > >> >>> > > >> [1] >>> > > >> >>> > > >> >>> > > >>> > >>> https://github.com/apache/cordova-coho/blob/master/docs/tools-release-pro >>> > > >>cess.md#test >>> > > >> [2] https://github.com/iandotkelly/nlf/pull/22 >>> > > >> >>> > > >> >>> > > >> >>> --------------------------------------------------------------------- >>> > > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> > > >> For additional commands, e-mail: dev-h...@cordova.apache.org >>> > > >> >>> > > >> >>> > > >>> > > >>> > > --------------------------------------------------------------------- >>> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> > > For additional commands, e-mail: dev-h...@cordova.apache.org >>> > > >>> > > >>> > >>> >> >> >
