El 07/05/11 15:31, intrigeri escribió:
> Hi,
>
> sajolida wrote (23 Apr 2011 21:10:47 GMT) :
>
>> 1. Since SHA-256 checking and OpenPGP validity check without WoT can
>> be put at the same level: basically trusting tails.boum.org, we
>> could choose to document only one of the two solutions.
>
> Agreed.
>
>> And the easiest to document well is SHA-256 ;) I didn't do it yet
>> but in the end I'm in favour of removing the "Using our OpenPGP
>> key" option from this first part.
>
> Seems to me both techniques involve the same steps (downloading an
> additional file, cd'ing to the right directory, running a command)
> => I fail to see why SHA-256 is easier to document.
I went for SHA-256 because it was easier to document for Windows users.
I might not have been really explicit while explaining myself but the
cool thing about the idea of using a Firefox extension to check the
SHA-256 is that it's cross-platform (even though it's cheesy).
My objective is to provide a level of trust equal to the one of
mainstream HTTPS for everybody. For sure, we could question the
relevance of providing such verification for people using proprietary
operating systems.
I had a look at possible GnuPG options for Windows user. The one
recommended by gnupg.org is Gpg4win. It doesn't work under Wine so I
couldn't test it so far. But for sure, it doesn't have a valid
mainstream HTTPS certificate ;) We could decide to mirror a « trusted »
version of it but I fear we don't feel like doing so.
> Moreover:
>
> 1. GNOME users can even get a right-click interface in Nautilus for
> OpenPGP detached signature checking.
> 2. Documenting the OpenPGP way paves the road to the more serious
> WoT-based method... and other OpenPGP uses we may want to promote,
> such as Monkeysphere.
I agree with that. The GnuPG option seems similarly easy for Linux/Gnome
users. So we could do instead:
- Using our OpenPGP key with Gnome (recommended, Linux: Tails, Ubuntu,
Debian, Fedora, etc.)
That would be the Seahorse + Nautilus right-click technique
- Using Firefox (easy, Windows & MAC)
That would be the fail-over SHA-256 technique for Windows users
- Using our OpenPGP key without Gnome (advanced, Linux)
Same as the actual one
If we go for that, we would still need to add the SHA-256 sum on the
download page but we could remove the .iso.sha256 file from the torrent
and mirror servers.
> => I'm rather in favour of removing the SHA-256 method.
It would be half-removed then ;)
>> 2. Since going through WoT checks on Tails' key not only depends on
>> technical knowledge but also on human interaction, real-life checks,
>> etc. I decided not to write a technical howto but rather an explanation
>> of the trust model issue, a broad picture on how could the WoT solve
>> this and hints on how to start building a trust path to Tails' key.
>
> Seems great to me.
>
>> I'm wondering now whether to include here in some form the technical
>> howto from the previous "Using our OpenPGP key". I thought that :
>> - people knowledgeable enough about OpenPGP to get and check a trust
>> path to Tails would probably be able to do that on their own, and
>> - we won't be able to give a full GnuPG training to people who are not
>> used to OpenPGP in our little howto and they would anyway need to
>> establish real-life contacts with other OpenPGP-savvy people in order to
>> get into the WoT.
>
> Agreed.
>
>> In the end I find my whole WoT explanation a bit absurd but don't really
>> know what to do about it.
>
> The LUG thing is the only part that sounds a bit funny to my hear, the
> rest is pretty good I think. Anyway: sure, all we can do is provide
> hints to the ones who would like to learn the WoT way. The LUG thing
> is one hint. A few others may be worth mentionning too.
>
> Did you consider suggesting Debian / Ubuntu users to go through the
> Debian keyring to bootstrap a trust-path to our key, that is signed by
> at least two Debian developers? E.g.:
>
> sudo apt-get install debian-keyring
> gpg --keyring=/usr/share/keyrings/debian-keyring.gpg --export CCD2ED94D21739E9 \
> | gpg --import
>
> (Micah's key is outdated and expired in current debian-keyring
> package, this is why the above example uses dkg's key instead.)
>
> Another (not perfect either) way to get our pubkey would be to
> download it several times, from several systems and locations, and
> make sure the end-result is consistent. Hard to explain, sure, and the
> ones who would do so may already know how and why to do it.
>
> What may be made clear is: establishing a trust-path may be painful,
> but it only needs to be done once.
Great. Thanks for those proposals, I'll incorporate them. They will
surely make the end of the doc on the WoT way less absurd. The day I
wrote all that was very long and I was having a hard time going further.
--
sajolida
