You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by se...@apache.org on 2018/08/23 18:01:30 UTC
svn commit: r1838746 - /subversion/site/staging/download.html
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
</code></p>
<p>Alternatively, you can verify the checksums on the
Re: svn commit: r1838746 - /subversion/site/staging/download.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
sebb AT ASF wrote on Tue, 28 Aug 2018 11:45 +0100:
> OK, so how do I do the merge?
>
> I tried using the following in a fresh checkout of the staging branch:
>
> svn merge ^/subversion/site/publish
>
> However it showed changes I have not made, so I am loath to commit them:
>
> $ svn -u st
> M 1839421 roadmap.html
> M 1839421 quick-start.html
> M 1839421 faq.html
> M 1839421 .
> Status against revision: 1839421
>
> Is this normal?
It's normal for publish to be ahead of staging. Just do a cherry-pick
merge from staging to publish: 'svn merge -cN ^/.../staging' in a wc of
publish. (A sync merge from staging to publish --- opposite of what you
tried --- might work too.)
Could you please use a log message of the form "* download.html..."?
That makes it easier for us to read the log later. See previous log
messages for examples or <https://subversion.apache.org/patches> for the
gory details. Thanks!
Re: svn commit: r1838746 - /subversion/site/staging/download.html
Posted by sebb AT ASF <se...@apache.org>.
OK, so how do I do the merge?
I tried using the following in a fresh checkout of the staging branch:
svn merge ^/subversion/site/publish
However it showed changes I have not made, so I am loath to commit them:
$ svn -u st
M 1839421 roadmap.html
M 1839421 quick-start.html
M 1839421 faq.html
M 1839421 .
Status against revision: 1839421
Is this normal?
On 25 August 2018 at 22:18, Stefan <lu...@posteo.de> wrote:
> On 25/08/2018 18:06, sebb AT ASF wrote:
>> On 25 August 2018 at 13:44, Stefan <lu...@posteo.de> wrote:
>>> On 25/08/2018 14:37, Stefan wrote:
>>>> On 23/08/2018 20:01, sebb@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
>
>
Re: svn commit: r1838746 - /subversion/site/staging/download.html
Posted by Stefan <lu...@posteo.de>.
On 25/08/2018 18:06, sebb AT ASF wrote:
> On 25 August 2018 at 13:44, Stefan <lu...@posteo.de> wrote:
>> On 25/08/2018 14:37, Stefan wrote:
>>> On 23/08/2018 20:01, sebb@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
Re: svn commit: r1838746 - /subversion/site/staging/download.html
Posted by Stefan <lu...@posteo.de>.
On 25/08/2018 18:06, sebb AT ASF wrote:
> On 25 August 2018 at 13:44, Stefan <lu...@posteo.de> wrote:
>> On 25/08/2018 14:37, Stefan wrote:
>>> On 23/08/2018 20:01, sebb@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
Re: svn commit: r1838746 - /subversion/site/staging/download.html
Posted by sebb AT ASF <se...@apache.org>.
On 25 August 2018 at 13:44, Stefan <lu...@posteo.de> wrote:
> On 25/08/2018 14:37, Stefan wrote:
>> On 23/08/2018 20:01, sebb@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?
> "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
>
Re: svn commit: r1838746 - /subversion/site/staging/download.html
Posted by sebb AT ASF <se...@apache.org>.
On 25 August 2018 at 13:44, Stefan <lu...@posteo.de> wrote:
> On 25/08/2018 14:37, Stefan wrote:
>> On 23/08/2018 20:01, sebb@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?
> "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
>
Re: svn commit: r1838746 - /subversion/site/staging/download.html
Posted by Stefan <lu...@posteo.de>.
On 25/08/2018 14:37, Stefan wrote:
> On 23/08/2018 20:01, sebb@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:
"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
Re: svn commit: r1838746 - /subversion/site/staging/download.html
Posted by Stefan <lu...@posteo.de>.
On 25/08/2018 14:37, Stefan wrote:
> On 23/08/2018 20:01, sebb@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:
"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
Re: svn commit: r1838746 - /subversion/site/staging/download.html
Posted by Stefan <lu...@posteo.de>.
On 23/08/2018 20:01, sebb@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?
> </code></p>
>
> <p>Alternatively, you can verify the checksums on the
>
Re: svn commit: r1838746 - /subversion/site/staging/download.html
Posted by Stefan <lu...@posteo.de>.
On 23/08/2018 20:01, sebb@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?
> </code></p>
>
> <p>Alternatively, you can verify the checksums on the
>