On Thu, Jan 10, 2013 at 23:43:07 +0100,
Björn Persson wrote:
And since people don't check the certificate anyway it would be better
if Firefox would silently switch to plain HTTP when it can't verify the
certificate? Not just use the unverified certificate but skip all the
cryptography altoge
On Thu, Jan 10, 2013 at 8:41 PM, Adam Jackson wrote:
> For the same reason Firefox doesn't automatically accept self-signed SSL
> certs, and the same reason that ssh doesn't automatically accept new
> host keys: it'd be creating trust from thin air. With secure boot
> disabled there's no root of
On Thu, 2013-01-10 at 21:49 +0100, Nicolas Mailhot wrote:
> Le Jeu 10 janvier 2013 20:41, Adam Jackson a écrit :
>
> > For the same reason Firefox doesn't automatically accept self-signed SSL
> > certs, and the same reason that ssh doesn't automatically accept new
> > host keys: it'd be creating
Nicolas Mailhot wrote:
>
> Le Jeu 10 janvier 2013 20:41, Adam Jackson a écrit :
>
>> For the same reason Firefox doesn't automatically accept self-signed SSL
>> certs, and the same reason that ssh doesn't automatically accept new
>> host keys: it'd be creating trust from thin air.
>
> Checking
Matthew Garrett wrote:
> On Wed, Jan 09, 2013 at 03:20:16PM +0100, Tomas Mraz wrote:
>> On Wed, 2013-01-09 at 14:15 +, Matthew Garrett wrote:
>> > Yes, if you boot an installer that doesn't verify signatures, you won't
>> > verify signatures.
>>
>> But then what's the difference from distrust
On Thu, Jan 10, 2013 at 03:53:04PM -0700, Stephen John Smoogen wrote:
> Then write the patch. That is all that this is going to take... even
> if it doesn't get incorporated it will be there for some probably
> large group that does want it (I would use it myself.) Because the
> current approach o
On Thu, Jan 10, 2013 at 04:42:36PM -0600, Michael Cronenworth wrote:
> Till Maas wrote:
> > SecureBoot does not do this automatically, as it would allow to run a
> > F18 install image that does no signature checking on packages. Therefore
> > users still need to verify the image that they are going
On 10 January 2013 15:43, Björn Persson wrote:
> Stephen John Smoogen wrote:
>> On 10 January 2013 14:17, Björn Persson wrote:
>> > Adam Jackson wrote:
>> >> On Thu, 2013-01-10 at 17:56 +0100, Till Maas wrote:
>> >> > But why should anaconda not verify packages if secure boot is disabled?
>> >>
>
Stephen John Smoogen wrote:
> On 10 January 2013 14:17, Björn Persson wrote:
> > Adam Jackson wrote:
> >> On Thu, 2013-01-10 at 17:56 +0100, Till Maas wrote:
> >> > But why should anaconda not verify packages if secure boot is disabled?
> >>
> >> For the same reason Firefox doesn't automatically a
Till Maas wrote:
> SecureBoot does not do this automatically, as it would allow to run a
> F18 install image that does no signature checking on packages. Therefore
> users still need to verify the image that they are going to boot with
> this feature enabled.
... you rolled problem 2 into problem
On Thu, Jan 10, 2013 at 04:25:18PM -0600, Michael Cronenworth wrote:
> Problem 1: Root trust
> Currently this process is manually performed by checking a mental
> checkbox when a user downloads a Fedora image from fp.o. Having
> SecureBoot perform this process automatically is a +1, but not a
> re
Stephen John Smoogen wrote:
> In every test I have seen on what people do.. it is a click through.
> People click on it without checking the certificate. That is what
> makes it theatre or CYA covering.. What the developer is saying is
> that he doesn't want to pursue security theatre himself on th
On Thu, Jan 10, 2013 at 02:41:54PM -0500, Adam Jackson wrote:
> On Thu, 2013-01-10 at 17:56 +0100, Till Maas wrote:
> > But why should anaconda not verify packages if secure boot is disabled?
>
> For the same reason Firefox doesn't automatically accept self-signed SSL
> certs, and the same reason
Adam Jackson writes:
> For the same reason Firefox doesn't automatically accept self-signed SSL
> certs, and the same reason that ssh doesn't automatically accept new
> host keys: it'd be creating trust from thin air.
I trust my hardware, I trust my firmware, I trust my install medium.
That is n
On 10 January 2013 14:17, Björn Persson wrote:
> Adam Jackson wrote:
>> On Thu, 2013-01-10 at 17:56 +0100, Till Maas wrote:
>> > But why should anaconda not verify packages if secure boot is disabled?
>>
>> For the same reason Firefox doesn't automatically accept self-signed SSL
>> certs, and the
Adam Jackson wrote:
> On Thu, 2013-01-10 at 17:56 +0100, Till Maas wrote:
> > But why should anaconda not verify packages if secure boot is disabled?
>
> For the same reason Firefox doesn't automatically accept self-signed SSL
> certs, and the same reason that ssh doesn't automatically accept new
Le Jeu 10 janvier 2013 20:41, Adam Jackson a écrit :
> For the same reason Firefox doesn't automatically accept self-signed SSL
> certs, and the same reason that ssh doesn't automatically accept new
> host keys: it'd be creating trust from thin air.
Checking packages are signed by the same key a
On Thu, 2013-01-10 at 17:56 +0100, Till Maas wrote:
> On Wed, Jan 09, 2013 at 10:09:21AM -0500, Peter Jones wrote:
>
> > As it stands you still need to verify that your netinst.iso (or
> > whatever) boot image is what you mean to be using. There are ways we
> > can address that, but it's not the
On Wed, Jan 09, 2013 at 10:09:21AM -0500, Peter Jones wrote:
> As it stands you still need to verify that your netinst.iso (or
> whatever) boot image is what you mean to be using. There are ways we
> can address that, but it's not the problem I'm trying to solve with this
> particular feature.
>
On Tue, Jan 8, 2013 at 10:15 AM, Peter Jones wrote:
> On Tue, Jan 08, 2013 at 11:04:30AM -0500, Steve Clark wrote:
> >
> > What about repins? I want to add my own custom package that is not
> signed and create a new CD with a custom ks.cfg.
> > How would that work?
>
> You'd generate your own key
On 01/09/2013 04:09 PM, Peter Jones wrote:
It just occurred to me that this has zero chance of working because
an attacker can always take the already-signed boot path from the
F18 installer and use that to boot a modified F19 installation
image. We cannot retroactively add these checks to the
On Wed, Jan 09, 2013 at 01:52:05PM +0100, Florian Weimer wrote:
> On 01/08/2013 04:25 PM, Jaroslav Reznik wrote:
> >Following the implementation of Features/SecureBoot, we can extend the Secure
> >Boot keys as a root of trust provided by the hardware against which we can
> >verify a signature on ou
On Wed, Jan 09, 2013 at 03:39:42PM +0100, Florian Weimer wrote:
> On 01/09/2013 03:26 PM, Peter Jones wrote:
>
> >You've misunderstood the mechanism at work. dhowell's current kernel
> >patch set allows you to add keys which are wrapped (in a well defined
> >way) in a pecoff binary that's signed
On 01/09/2013 03:26 PM, Peter Jones wrote:
You've misunderstood the mechanism at work. dhowell's current kernel
patch set allows you to add keys which are wrapped (in a well defined
way) in a pecoff binary that's signed by already trusted keys. This is
what I'm referring to above when I say "g
On Wed, Jan 09, 2013 at 03:20:16PM +0100, Tomas Mraz wrote:
> On Wed, 2013-01-09 at 14:15 +, Matthew Garrett wrote:
> > Yes, if you boot an installer that doesn't verify signatures, you won't
> > verify signatures.
>
> But then what's the difference from distrusting the contents of an
> inst
On Wed, Jan 09, 2013 at 11:55:42AM +0100, Florian Weimer wrote:
> On 01/08/2013 07:15 PM, Peter Jones wrote:
> >On Tue, Jan 08, 2013 at 11:04:30AM -0500, Steve Clark wrote:
> >>
> >>What about repins? I want to add my own custom package that is not signed
> >>and create a new CD with a custom ks.c
On Wed, 2013-01-09 at 14:15 +, Matthew Garrett wrote:
> On Wed, Jan 09, 2013 at 03:08:51PM +0100, Florian Weimer wrote:
>
> > I start with the F18 TC3 image, which boots on Secure Boot systems,
> > replace the boot artwork (which is not cryptographically protected),
> > the F18 kernel, and us
On Wed, Jan 09, 2013 at 03:08:51PM +0100, Florian Weimer wrote:
> I start with the F18 TC3 image, which boots on Secure Boot systems,
> replace the boot artwork (which is not cryptographically protected),
> the F18 kernel, and use most of the F19 installation environment.
> The F18 boot loader and
On 01/09/2013 02:34 PM, Matthew Garrett wrote:
On Wed, Jan 09, 2013 at 01:52:05PM +0100, Florian Weimer wrote:
It just occurred to me that this has zero chance of working because
an attacker can always take the already-signed boot path from the
F18 installer and use that to boot a modified F19
On Wed, Jan 09, 2013 at 01:52:05PM +0100, Florian Weimer wrote:
> It just occurred to me that this has zero chance of working because
> an attacker can always take the already-signed boot path from the
> F18 installer and use that to boot a modified F19 installation
> image. We cannot retroactiv
On 01/08/2013 04:25 PM, Jaroslav Reznik wrote:
Following the implementation of Features/SecureBoot, we can extend the Secure
Boot keys as a root of trust provided by the hardware against which we can
verify a signature on our key files, thus guaranteeing that they're from the
same source as the b
On 01/08/2013 07:15 PM, Peter Jones wrote:
On Tue, Jan 08, 2013 at 11:04:30AM -0500, Steve Clark wrote:
What about repins? I want to add my own custom package that is not signed and
create a new CD with a custom ks.cfg.
How would that work?
You'd generate your own key, and people using your
On Tue, Jan 08, 2013 at 03:20:41PM -0500, Peter Jones wrote:
> On Tue, Jan 08, 2013 at 08:28:03PM +0100, Björn Persson wrote:
>
> > I'll agree that most users probably don't verify their DVD images as it
> > takes some manual work to do it properly, so that's another weak link,
> > but the possibi
On Tue, Jan 08, 2013 at 08:28:03PM +0100, Björn Persson wrote:
> I'll agree that most users probably don't verify their DVD images as it
> takes some manual work to do it properly, so that's another weak link,
> but the possibility does exist for those of us who care enough about
> our security.
Peter Jones wrote:
> On Tue, Jan 08, 2013 at 05:46:04PM +0100, Björn Persson wrote:
> > In my opinion, if Anaconda finds that it was booted without Secure
> > Boot, then it should assume that the user has verified the checksum on
> > the installation image and that the keys therein are therefore tr
On Tue, Jan 08, 2013 at 11:04:30AM -0500, Steve Clark wrote:
>
> What about repins? I want to add my own custom package that is not signed and
> create a new CD with a custom ks.cfg.
> How would that work?
You'd generate your own key, and people using your packages, who have
presumably decided th
On Tue, Jan 08, 2013 at 05:46:04PM +0100, Björn Persson wrote:
> > One long-standing problem in Fedora is that we don't check package
> > signatures
> > during installation.
> [...]
> > Following the implementation of Features/SecureBoot, we can extend the
> > Secure
> > Boot keys as a root of tr
> One long-standing problem in Fedora is that we don't check package signatures
> during installation.
[...]
> Following the implementation of Features/SecureBoot, we can extend the Secure
> Boot keys as a root of trust provided by the hardware against which we can
> verify a signature on our key f
On 01/08/2013 10:55 AM, Peter Jones wrote:
On Tue, Jan 08, 2013 at 03:52:02PM +, Petr Pisar wrote:
On 2013-01-08, Jaroslav Reznik wrote:
= Features/PackageSignatureCheckingDuringInstall =
https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringInstall
* Detailed description:
On Tue, Jan 08, 2013 at 03:52:02PM +, Petr Pisar wrote:
> On 2013-01-08, Jaroslav Reznik wrote:
> >
> >= Features/PackageSignatureCheckingDuringInstall =
> > https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringInstall
> >
> > * Detailed description:
> > One long-standing prob
On 2013-01-08, Jaroslav Reznik wrote:
>
>= Features/PackageSignatureCheckingDuringInstall =
> https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringInstall
>
> * Detailed description:
> One long-standing problem in Fedora is that we don't check package signatures
> during installat
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.
= Features/PackageSignatureCheckingDuringInstall =
https://fedorapr
42 matches
Mail list logo
