On Thu, 2019-08-08 at 16:24 +0200, Björn Persson wrote:
> Joe Orton wrote:
> > If you don't enforce GPG verification at or before "fedpkg upload" there
> > is no assurance that what hits the lookaside cache is trusted, so I
> > agree - doing this at build time is a good example of not caring
Joe Orton wrote:
> If you don't enforce GPG verification at or before "fedpkg upload" there
> is no assurance that what hits the lookaside cache is trusted, so I
> agree - doing this at build time is a good example of not caring about
> security until it's too late.
I hope most people reading
On Thu, Jul 25, 2019 at 07:22:56PM +0200, Björn Persson wrote:
> Jason L Tibbitts III wrote:
> > > "JO" == Joe Orton writes:
> >
> > JO> In the historic CVS-based build system which predated what we now
> > JO> use, we could do GPG key verification at the time of downloading and
> > JO>
Jason L Tibbitts III wrote:
> > "JO" == Joe Orton writes:
>
> JO> In the historic CVS-based build system which predated what we now
> JO> use, we could do GPG key verification at the time of downloading and
> JO> importing a new tarball.
>
> You're right; tmz dug up a copy of the old
> "JO" == Joe Orton writes:
JO> In the historic CVS-based build system which predated what we now
JO> use, we could do GPG key verification at the time of downloading and
JO> importing a new tarball.
You're right; tmz dug up a copy of the old Makefile.common file:
On 2019-07-25, Björn Persson wrote:
> Verifying the signature as part of the build ensures that packagers
> don't forget to verify it.
>
Then it's a job for "fedpkg new-sources" or spectool, not for rpmbuild.
>> (4) Verification of modified archives conflicts with a legal requirement
>> that
Le 2019-07-25 12:17, Björn Persson a écrit :
Hit,
An RPM spec is not a place for golfing. Readable code takes priority
over saving keystrokes.
Then it should be implemented cleanly in a declarative syntax,
with %{gpg_signatureX} and %{gpg_keyringX} variables matching
%{sourceX}, and a
Pierre-Yves Chibon wrote:
> I'm more worried about it relying on GPG at the moment considering the state
> of
> the SKS network [1].
> What are the changes that we end up breaking a build if we suddenly get a
> poisoned key? Are we going to break just a build or could this have more
> annoying
On Thu, Jul 25, 2019 at 12:46:11PM +0200, Björn Persson wrote:
> Joe Orton wrote:
> > We'd put the set of trusted GPG keys in the repository alongside the
> > spec file, using some standard filename, and the build system would try
> > check the .asc against the keys when downloading (or
Joe Orton wrote:
> On Wed, Jul 24, 2019 at 11:15:26PM +0200, Igor Gnatenko wrote:
> > Hello,
> >
> > we've got new section in Packaging Guidelines about verifying upstream
> > sources[0] with GPG. Please use it whenever possible :)
> >
> > Thanks!
> >
> >
> > [0]
> >
Hello, Remi Collet.
Thu, 25 Jul 2019 11:16:54 +0200 you wrote:
> Additional question, what will happen when the key will expire ?
Expired keys cannot be used for signing or encrypting. But they still
can be used for decrypting and verifying signatures.
--
Sincerely,
Vitaly Zaitsev
On Thu, Jul 25, 2019 at 06:46:24AM -, Petr Pisar wrote:
> On 2019-07-24, Igor Gnatenko wrote:
> > we've got new section in Packaging Guidelines about verifying upstream
> > sources[0] with GPG. Please use it whenever possible :)
> [...]
> > [0]
> >
Vít Ondruch wrote:
> Dne 25. 07. 19 v 8:46 Petr Pisar napsal(a):
> > (1) I don't agree this feature is helpful. If we don't trust ./sources
> > file content in dist-git, we cannot trust keyring stored in the the same
> > dist-git repository. In other words it only brings another code into
> > spec
Petr Pisar wrote:
> On 2019-07-24, Igor Gnatenko wrote:
> > we've got new section in Packaging Guidelines about verifying upstream
> > sources[0] with GPG. Please use it whenever possible :)
> [...]
> > [0]
> >
BTW, there is this proposal:
https://github.com/rpm-software-management/rpm/issues/463
Vít
Dne 25. 07. 19 v 11:17 Joe Orton napsal(a):
> On Wed, Jul 24, 2019 at 11:15:26PM +0200, Igor Gnatenko wrote:
>> Hello,
>>
>> we've got new section in Packaging Guidelines about verifying upstream
>>
On Wed, Jul 24, 2019 at 11:15:26PM +0200, Igor Gnatenko wrote:
> Hello,
>
> we've got new section in Packaging Guidelines about verifying upstream
> sources[0] with GPG. Please use it whenever possible :)
>
> Thanks!
>
>
> [0]
>
Additional question, what will happen when the key will expire ?
Ok, probably not going to happen in Fedora, but may happen in some other
distributions, supported for more years
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Le 24/07/2019 à 23:15, Igor Gnatenko a écrit :
> Hello,
>
> we've got new section in Packaging Guidelines about verifying upstream
> sources[0] with GPG. Please use it whenever possible :)
Looking at the Guidelines...
Implementing it for PHP...
I agree with Petr and Wit, I don't see any real
Dne 25. 07. 19 v 8:46 Petr Pisar napsal(a):
> On 2019-07-24, Igor Gnatenko wrote:
>> we've got new section in Packaging Guidelines about verifying upstream
>> sources[0] with GPG. Please use it whenever possible :)
> [...]
>> [0]
>>
On 2019-07-24, Igor Gnatenko wrote:
> we've got new section in Packaging Guidelines about verifying upstream
> sources[0] with GPG. Please use it whenever possible :)
[...]
> [0]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification
May I know a FPC ticket where
Hello,
we've got new section in Packaging Guidelines about verifying upstream
sources[0] with GPG. Please use it whenever possible :)
Thanks!
[0]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification
___
devel mailing
21 matches
Mail list logo
