On 25/08/2018 18:06, sebb AT ASF wrote:
> On 25 August 2018 at 13:44, Stefan <luke1410_at_posteo.de> wrote:
>> On 25/08/2018 14:37, Stefan wrote:
>>> On 23/08/2018 20:01, sebb_at_apache.org wrote:
>>>> Author: sebb
>>>> Date: Thu Aug 23 18:01:30 2018
>>>> New Revision: 1838746
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1838746&view=rev
>>>> Log:
>>>> SVN-4736 - fix gpg command
>>>>
>>>> Modified:
>>>> subversion/site/staging/download.html
>>>>
>>>> Modified: subversion/site/staging/download.html
>>>> URL: http://svn.apache.org/viewvc/subversion/site/staging/download.html?rev=1838746&r1=1838745&r2=1838746&view=diff
>>>> ==============================================================================
>>>> --- subversion/site/staging/download.html (original)
>>>> +++ subversion/site/staging/download.html Thu Aug 23 18:01:30 2018
>>>> @@ -253,7 +253,7 @@ Other mirrors:
>>>> <em>or</em><br />
>>>> <code>
>>>> % gpg --import subversion.asc<br />
>>>> -% gpg --verify subversion-[version].tar.gz.asc
>>>> +% gpg --verify subversion-[version].tar.gz.asc subversion-[version].tar.gz
>>> Testing GPG locally (2.2.8 - Windows 10 - bundled version with Gpg4Win
>>> 3.1.2) running the command w/o specifying the filename of the gz archive
>>> works fine:
>>> "gpg: assuming signed data in 'subversion-1.10.2.tar.bz2' [...]"
>>>
>>> Is this command problematic with older GPG versions? If not, why not
>>> keep the command as short as possible and rely on the default resolution
>>> of the archive name?
>> Just saw the referenced SVN issue with the link which gives the missing
>> rational for that change. Thanks for that (should have spotted it before
>> replying). For the record:
> Would it be useful to link to the explanation from the download page?
I would not think so. The target audience of that article is primarily
the user who's downloading the package. We'd provide him with proper
details about how to verify the download, but anything which explains
the rational behind how the tech side of the verification works and why
the command should be written the way it's presented in the example
would be out of scope for that page, IMO. The rational why something was
done the way it was should be in the log (and there it's already present
via the Jira issue link).
>
>> "If the release file is omitted, GPG will only check the signature
>> against the release file if the signature is a detached signature. If
>> the .asc file is a self-contained signed file, GPG will only check that,
>> and will not verify the release. (This should not happen if the
>> signature file was downloaded from an ASF server, but it is safer to
>> always specify the release filename)" [1]
>>
>> That said, +1 on that change. Feel free to merge it to publish.
>>
>> [1] https://www.apache.org/info/verification.html#CheckingSignatures
>>>> </code></p>
>>>>
>>>> <p>Alternatively, you can verify the checksums on the
>>>>
>> Regards,
>> Stefan
>>
Regards,
Stefan
Received on 2018-08-25 23:18:56 CEST