Tails

#1 Updated by intrigeri 2017-09-18 11:21:25

• Assignee set to sajolida

The timezone issue is clearly a doc problem.

The other two issues might be caused by our release process doc (that iirc you made generate these files) assuming too much about the RM’s gpg.conf. Likely we need to enforce the output format better when generating this file.

#2 Updated by sajolida 2017-09-27 09:19:49

• blocks Feature #13423: Core work 2017Q3: Technical writing added

#3 Updated by sajolida 2017-10-02 18:17:37

• Description updated

#4 Updated by sajolida 2017-10-02 18:19:36

• Subject changed from Verification instructions for Debian, Ubuntu to Fix differences in OpenPGP verification outputs
• Category set to Installation
• Status changed from New to Confirmed

#5 Updated by sajolida 2017-10-02 18:19:52

• blocks Feature #14758: Core work 2017Q4 → 2018Q1: Technical writing added

#6 Updated by sajolida 2017-10-02 18:21:29

• blocked by deleted (Feature #13423: Core work 2017Q3: Technical writing)

#7 Updated by Anonymous 2018-01-17 11:10:58

• QA Check set to Info Needed

@sajolida, I don’t quite understand how you process these tickets as being or not being part of core work. Did you take it out because of lack of time or because you deem it’s not that important? In the first case, maybe it should go to the next quarter of core work.

#8 Updated by sajolida 2018-02-24 11:48:59

• Assignee changed from sajolida to bertagaz
• Target version set to Tails_3.6
• QA Check changed from Info Needed to Ready for QA
• Feature Branch set to web/14977-improve-openpgp-instructions

Dear release manager, what about this?

#9 Updated by bertagaz 2018-02-24 12:27:27

• Assignee changed from bertagaz to sajolida
• QA Check changed from Ready for QA to Info Needed

sajolida wrote:
> Dear release manager, what about this?

Several things:

You sneak into this branch a lot of commits rewriting the OpenPGPP verification explanation coming from Feature #14977. I’ll ignore them as being part of this other ticket review job. It does not help to know what to review here though. :)

It’s good you make it clear that the signature date is older than the release date, and how much.

I wonder if it’s enough though. Maybe we should still also mention as proposed that the timezones between what gpg will output to the user and what we provide as a result will be differents? Or do you think ‘at most 5 days older’ is enough and adding more will be too confusing?

#12 Updated by sajolida 2018-02-24 16:36:42

• Status changed from Confirmed to In Progress

Applied in changeset commit:29e9d9b2b92c4bffe113a724f139bc78a36b87da.

#13 Updated by intrigeri 2018-02-28 09:24:55

• % Done changed from 0 to 70
• QA Check changed from Info Needed to Dev Needed

I’m not sure about the replacement of ----keyid-format 0xlong with --no-options. I think it’s good to add --no-options because it makes the output less dependent on the RM’s personal GnuPG configuration. But if we don’t specify anything else, we end up depending on the RM’s GnuPG version. Given the default output format may change accross GnuPG versions, I think the problem this ticket is about would be addressed more robustly if we also specified the exact output format we want, e.g. --no-options --keyid-format 0xlong --with-fingerprint.

Also, to ensure the output the user sees matches what we publish, I think wiki/src/inc/stable_amd64_gpg_verify.html should pass the exact same options as the one used in the release process doc, including --no-options (and if you agree with the above, the 2 options I propose we add).

What do you think?

#14 Updated by sajolida 2018-03-13 13:08:11

• Target version changed from Tails_3.6 to Tails_3.7

#15 Updated by sajolida 2018-03-22 18:47:36

• File wrapped.png added
• Assignee changed from sajolida to intrigeri
• QA Check changed from Dev Needed to Ready for QA

• I forced —keyid-format 0xlong in 914f169e0c. I didn’t think that different versions of GnuPG could lead to different format.
• I updated /wiki/src/inc/stable_amd64_gpg_verify.html. I didn’t realize that it was not updated automatically elsewhere already.
• I updated /wiki/src/inc/stable_amd64_gpg_signature_output.html to used TZ=UTC.

I also added —with-fingerprint in b2af8110b2 but I’m not really convinced by this one because:

• It’s not fixing differences in the output but adding additional information:

 Primary key fingerprint: A490 D0F4 D311 A415 3E2B  B7CA DBB8 02B2 58AC D84F
     Subkey fingerprint: CD4D 4351 AFA6 933F 574A  9AFB 90B2 B4BD 7AED 235F

Is this extra information useful to fix the problem we’re having here?

• It makes the command line longer and wraps on our website. Wrapped command lines are problematic for people to follow but maybe we can assume that people following these instructions can figure that out.
  See attachment.

#16 Updated by intrigeri 2018-03-26 07:19:46

• Assignee changed from intrigeri to sajolida
• QA Check changed from Ready for QA to Info Needed

I can’t find the topic branch nor any of the commits you’re referring to in our Git repo. Maybe you forgot to push?

> I also added —with-fingerprint in b2af8110b2 but I’m not really convinced by this one because:

> * It’s not fixing differences in the output but adding additional information:

>

>  Primary key fingerprint: A490 D0F4 D311 A415 3E2B  B7CA DBB8 02B2 58AC D84F
>      Subkey fingerprint: CD4D 4351 AFA6 933F 574A  9AFB 90B2 B4BD 7AED 235F
> 

> Is this extra information useful to fix the problem we’re having here?

I’m confused: according to the OP, the problem we’re having here is “There are three differences between actual and expected output […]”, and one of these differences is whether the output includes the fingerprints or not (the one we publish will include them in most cases as long as the RM complies with our security policy, the one the user will see won’t include them unless they’ve added a non-default setting to their GnuPG configuration). I don’t know if I’m nitpicking or merely reminding you of what lead someone to open this ticket in the first place. I’ll let you take a step back and make the call! :)

> * It makes the command line longer and wraps on our website. Wrapped command lines are problematic for people to follow but maybe we can assume that people following these instructions can figure that out.

Perhaps this would address this problem:

gpg --no-options --keyid-format 0xlong --with-fingerprint \
--verify tails-amd64-3.6.1.iso.sig tails-amd64-3.6.1.iso

… or this, but it’s perhaps too clever for this context:

gpg --no-options --keyid-format 0xlong --with-fingerprint --verify tails-amd64-3.6.1.iso{.sig,}

#17 Updated by sajolida 2018-03-27 11:24:08

• Assignee changed from sajolida to intrigeri
• QA Check changed from Info Needed to Ready for QA

Sorry for the mess when pushing the other day. Now origin/web/14977-improve-openpgp-instructions should be at 28409eee0d.

The problem raised by the OT is that the two outputs were different. The one from the RM included the fingerprints as they have with-fingerprint in their gpg.conf as per our security policy.

But now that we force the RM to use --no-options, the fingerprints are not in the outputs anymore. I checked on my setup and it works (I also have with-fingerprint in my gpg.conf).

So both outputs are now the same and the initial problem is solved, though both outputs come with no fingerprint.

My branch at 28409eee0d has no fingerprints.

#18 Updated by intrigeri 2018-03-27 14:48:12

• QA Check changed from Ready for QA to Pass

> But now that we force the RM to use --no-options, the fingerprints are not in the outputs anymore.

Right, sorry I forgot that between 2 rounds of reviews :/

> So both outputs are now the same and the initial problem is solved, though both outputs come with no fingerprint.

Great, going to merge :)))

#19 Updated by intrigeri 2018-03-27 14:53:30

• Status changed from In Progress to Resolved
• % Done changed from 70 to 100

Applied in changeset commit:100c43b85df0e5a9ad4880e81278c6ef2648c3e1.

#20 Updated by intrigeri 2018-03-27 14:55:04

• Assignee deleted (intrigeri)

#21 Updated by sajolida 2018-11-18 17:36:37

• related to Bug #16112: Confusing signature date on website doc added