On Thu, Mar 31, 2016 at 02:39:41PM -, Ralf Senderek wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > I don't buy that reasoning. You sign stuff to prevent silent
> > modification (because of malice or corruption), and not to track
> > changes, we have better mechanisms for that.
>
> Signing is
Zbigniew Jędrzejewski-Szmek wrote:
> I don't buy that reasoning. You sign stuff to prevent silent
> modification (because of malice or corruption), and not to track
> changes, we have better mechanisms for that.
Signing is much more than an integrity proof for which hash values would
suffice.The
On Thu, Mar 31, 2016 at 01:39:17PM -, Ralf Senderek wrote:
> But the MUST has some implications:
>
> 1) The packager's trust-building activities into the public key are by no
> means optional.
Yes, the whole exercise would be pointless otherwise.
> 2) Patches, that are applied to the signed
With my upstream hat on, I'm all for a MUST, because it's the only way that
upstream can control what goes into Fedora. Without checking signatures or
tarball hashes, it's too easy to end up with questionable code.
But the MUST has some implications:
1) The packager's trust-building activities in
On Wed, Mar 30, 2016 at 11:38:28AM -0500, Michael Catanzaro wrote:
> On Wed, 2016-03-30 at 15:57 +, Ralf Senderek wrote:
> > It cannot be automated, because it relies on using the correct public
> > key, which always has to be checked manually by the packager
> > (including the use of gpg).
>
On Wed, Mar 30, 2016 at 04:19:49PM -, Ralf Senderek wrote:
> In case of an incident where the private key may be compromized, upstream
> is required to build the trust into the new key from the ground up.
>
> As these cases can be quite complicated and would need some serious actions
> on beha
On Wed, Mar 30, 2016 at 04:31:14PM +0100, James Hogarth wrote:
> On 30 March 2016 at 15:45, Zbigniew Jędrzejewski-Szmek
> wrote:
>
> > On Wed, Mar 30, 2016 at 02:44:44PM +, Zbigniew Jędrzejewski-Szmek
> > wrote:
> > > On Wed, Mar 30, 2016 at 02:26:59PM -, Ralf Senderek wrote:
> > > [snip
On Wed, 2016-03-30 at 15:57 +, Ralf Senderek wrote:
> It cannot be automated, because it relies on using the correct public
> key, which always has to be checked manually by the packager
> (including the use of gpg).
I mean, after the packager manually configures signature checking the
first t
> On Wed, Mar 30, 2016 at 02:26:59PM -, Ralf Senderek wrote:
> [snip the part I complete agree with]
...
> In fact signatures and license files are quite similar:
> our guidelines say that the license file MUST be installed if provided
> by upstream, and packagers SHOULD ask upstream to provide
Michael Catanzaro writes:
> Yeah, if this isn't automated SOMEHOW, I'm not going to do it, because
> I don't understand how to use GPG. I doubt I'm unusual in this
> regard
It cannot be automated, because it relies on using the correct public key,
which always has to be checked manually by th
On Wed, 2016-03-30 at 12:14 +, Zbigniew Jędrzejewski-Szmek wrote:
> I don't think you can discount this. Most maintainers don't check the
> tarballs they download if they build fine, afaik. Checking the
> signatures in %prep would force a significant change to how we build
> srpms.
Yeah, if th
On 30 March 2016 at 15:45, Zbigniew Jędrzejewski-Szmek
wrote:
> On Wed, Mar 30, 2016 at 02:44:44PM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Wed, Mar 30, 2016 at 02:26:59PM -, Ralf Senderek wrote:
> > [snip the part I complete agree with]
> >
> > > Having said the above, I also advoc
On Wed, Mar 30, 2016 at 02:44:44PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Mar 30, 2016 at 02:26:59PM -, Ralf Senderek wrote:
> [snip the part I complete agree with]
>
> > Having said the above, I also advocate a SHOULD instead of a MUST in
> > the guidelines as providing a signatu
On Wed, Mar 30, 2016 at 02:26:59PM -, Ralf Senderek wrote:
[snip the part I complete agree with]
> Having said the above, I also advocate a SHOULD instead of a MUST in
> the guidelines as providing a signature with the source tarball is
> voluntary for upstream and should be viewed as an addit
James Hogarth wrote:
> We trust our packagers to do a lot, we can trust them to add this to their
> packages if it helps them and for them to encourage it in their reviews if
> they find a signed archive provided upstream.
IMHO, this is the main point. Checking signatures automatically in %prep o
On 30 Mar 2016 13:15, "Zbigniew Jędrzejewski-Szmek"
wrote:
>
> On Wed, Mar 30, 2016 at 07:01:53AM +0100, James Hogarth wrote:
> > And of course with the packager uploading both the key and the archive
to
> > git with no net access in koji to verify the key I really don't see what
> > this actually
On Wed, Mar 30, 2016 at 07:01:53AM +0100, James Hogarth wrote:
> And of course with the packager uploading both the key and the archive to
> git with no net access in koji to verify the key I really don't see what
> this actually gives us
The signature and key can be verified by anyone. The signat
On 29 Mar 2016 18:08, "Ralf Senderek" wrote:
>
> > David Woodhouse wrote:
>
> > If we need to repackage the tarball to remove patent-encumbered or
otherwise
> > illegal or non-redistributable files, we cannot do this.
>
> I think , we can. Because the check in %prep should make sure that you've
go
Ralf Senderek wrote:
> I think , we can. Because the check in %prep should make sure that you've
> got the real thing. It doesn't require that you have to package everything
> that makes up the source after extraction. --
We can't. The upstream signatures are for the complete tarballs including
t
> David Woodhouse wrote:
> If we need to repackage the tarball to remove patent-encumbered or otherwise
> illegal or non-redistributable files, we cannot do this.
I think , we can. Because the check in %prep should make sure that you've got
the real thing.
It doesn't require that you have to pa
David Woodhouse wrote:
> Our packaging guidelines really ought to mandate that *if* upstream
> publishes GPG or PKCS#7/CMS signatures of source tarballs, then the
^
and if the upstream tarball can legally be redistributed as is
> package *m
On Thu, Mar 24, 2016 at 10:28:45AM +0100, Björn Persson wrote:
> David Woodhouse wrote:
> > Our packaging guidelines really ought to mandate that *if* upstream
> > publishes GPG or PKCS#7/CMS signatures of source tarballs, then the
> > package *must* verify those signatures as part of %prep.
>
> I
David Woodhouse wrote:
> Our packaging guidelines really ought to mandate that *if* upstream
> publishes GPG or PKCS#7/CMS signatures of source tarballs, then the
> package *must* verify those signatures as part of %prep.
I just thought of something that shouldn't be forgotten: How would this
affe
On Tue, Mar 22, 2016 at 10:45:59PM +0100, Björn Persson wrote:
> I suppose so, at least if the key is specified as only a filename. What
> will it do if a URL to the key is provided, and the key at that location
> has been modified? Will it replace the key with the modified one in the
> scratch bu
On Tue, 2016-03-22 at 18:29 +0100, Till Maas wrote:
> I already meant to file this feature request after discussing this with
> Werner Koch, so here it is and hopefully it will really be implemented:
> https://bugs.gnupg.org/gnupg/issue2290
Excellent; thank you. And in the meantime it's possible j
On Tue, 2016-03-22 at 22:45 +0100, Björn Persson wrote:
>
> I suppose so, at least if the key is specified as only a filename. What
> will it do if a URL to the key is provided, and the key at that location
> has been modified? Will it replace the key with the modified one in the
> scratch build,
On Tue, Mar 22, 2016 at 2:45 PM, Björn Persson wrote:
>
> Till Maas wrote:
> > I guess it might even make the new hotness do scratch builds with
> > verified tarballs, since iirc it updates both the tarball and the
> > signature and then %prep makes sure that they are verified.
>
> I suppose so, a
Till Maas wrote:
> I guess it might even make the new hotness do scratch builds with
> verified tarballs, since iirc it updates both the tarball and the
> signature and then %prep makes sure that they are verified.
I suppose so, at least if the key is specified as only a filename. What
will it do
On Tue, 2016-03-22 at 18:01 +0100, Björn Persson wrote:
> Because technically, verifying a tarball that the packager uploaded,
> with a signature that the packager uploaded, against a key that the
> packager uploaded, that doesn't really add anything compared to the
> packager verifying the signatu
On Tue, Mar 22, 2016 at 1:30 PM, Till Maas wrote:
> On Tue, Mar 22, 2016 at 09:12:15AM -0400, Josh Boyer wrote:
>
>> As an aside, I think Till has code written to make the lookaside use
>> sha256. I'm not sure what the next steps are to get that rolled out
>> though.
>
> Just for the record: Math
On Tue, Mar 22, 2016 at 06:01:28PM +0100, Björn Persson wrote:
> David Woodhouse wrote:
> > Our packaging guidelines really ought to mandate that *if* upstream
> > publishes GPG or PKCS#7/CMS signatures of source tarballs, then the
> > package *must* verify those signatures as part of %prep.
>
> I
On Tue, Mar 22, 2016 at 09:12:15AM -0400, Josh Boyer wrote:
> As an aside, I think Till has code written to make the lookaside use
> sha256. I'm not sure what the next steps are to get that rolled out
> though.
Just for the record: Mathieu wrote the code/did the work for this.
--
devel mailing l
On Tue, Mar 22, 2016 at 01:02:40PM +, David Woodhouse wrote:
> On Mon, 2016-03-21 at 18:02 +0100, Till Maas wrote:
> >
> > It is a simple one-liner if you use gpgv2:
> > http://pkgs.fedoraproject.org/cgit/rpms/youtube-dl.git/tree/youtube-dl.spec#n35
>
> That's better than my version; thanks.
David Woodhouse wrote:
> On Mon, 2016-03-21 at 18:02 +0100, Till Maas wrote:
> >
> > It is a simple one-liner if you use gpgv2:
> > http://pkgs.fedoraproject.org/cgit/rpms/youtube-dl.git/tree/youtube-dl.spec#n35
> >
>
> That's better than my version; thanks. It also means there's probably
> n
David Woodhouse wrote:
> Our packaging guidelines really ought to mandate that *if* upstream
> publishes GPG or PKCS#7/CMS signatures of source tarballs, then the
> package *must* verify those signatures as part of %prep.
I suppose the point of this would be that others can see that the
verificati
On Tue, 2016-03-22 at 09:12 -0400, Josh Boyer wrote:
> On Tue, Mar 22, 2016 at 9:02 AM, David Woodhouse > wrote:
> >
> > The original draft does raise an interesting question — do we need
> > to put the upstream PGP key directly into the package git tree
> > instead of the lookaside cache?
> >
>
On Tue, Mar 22, 2016 at 9:02 AM, David Woodhouse wrote:
> The original draft does raise an interesting question — do we need to
> put the upstream PGP key directly into the package git tree instead of
> the lookaside cache?
>
> I suppose while the lookaside cache is still only using MD5(!) to
> va
On Mon, 2016-03-21 at 18:02 +0100, Till Maas wrote:
>
> It is a simple one-liner if you use gpgv2:
> http://pkgs.fedoraproject.org/cgit/rpms/youtube-dl.git/tree/youtube-dl.spec#n35
That's better than my version; thanks. It also means there's probably
not a lot of point in trying to simplify it wi
On Mon, Mar 21, 2016 at 10:25:43AM +, David Woodhouse wrote:
> It might be nice to provide some RPM macros to make that easier for
> packagers.
It is a simple one-liner if you use gpgv2:
http://pkgs.fedoraproject.org/cgit/rpms/youtube-dl.git/tree/youtube-dl.spec#n35
Thank you for raising aw
On Mon, 2016-03-21 at 10:25 +, David Woodhouse wrote:
> Michael, you make a very good point at
> https://blogs.gnome.org/mcatanzaro/2016/03/13/do-you-trust-this-packa
> ge/
>
> Our packaging guidelines really ought to mandate that *if* upstream
> publishes GPG or PKCS#7/CMS signatures of sour
40 matches
Mail list logo
