On Wed, 20 Feb 2013 21:37:38 +
"Robin H. Johnson" wrote:
> Ideally keeping your primary key offline to increase security.
>
> However, the original theory was that if there was some attack that
> required a large amount of ciphertext or a targeted plaintext input,
> you would be limiting the
On Wed, Feb 20, 2013 at 09:38:38PM +0100, Luis Ressel wrote:
> On Mon, 18 Feb 2013 23:27:46 +
> "Robin H. Johnson" wrote:
> > 3. Dedicated Gentoo signing subkey
> What's the point of this, btw?
Ideally keeping your primary key offline to increase security.
However, the original theory was tha
On Wed, Feb 20, 2013 at 09:22:05PM +0100, Andreas K. Huettel wrote:
> Which of course brings up the question, why the hardcoded 4096 limit in
> GnuPG... but I guess that's not our problem yet.
> https://www.google.de/search?q=gnupg+rsa+8192
Standards interoperability. >RSA4096 will not work on leg
On Mon, 18 Feb 2013 23:27:46 +
"Robin H. Johnson" wrote:
> 3. Dedicated Gentoo signing subkey
What's the point of this, btw?
Luis
signature.asc
Description: PGP signature
Am Mittwoch, 20. Februar 2013, 20:36:22 schrieb Robin H. Johnson:
>
> Speed for i7-2600K CPU:
> DSA1024 0.007980s
> DSA2048 0.011940s
> DSA3072 0.013530s
> RSA1024 0.007000s
> RSA2048 0.012290s
> RSA3072 0.018420s
> RSA4096 0.030800s
>
Which of course brings up the question, why the hardcoded 40
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2013 12:32 PM, Diego Elio Pettenò wrote:
> On 20/02/2013 18:28, Rich Freeman wrote:
>> Agreed, especially if only 1-2 files are involved. If it is a bunch
>> that could get unwieldy. Wasn't really thinking about that option.
>
> That being
On Wed, Feb 20, 2013 at 01:41:03PM -0500, James Cloos wrote:
> > "RHJ" == Robin H Johnson writes:
>
> RHJ> 2. Root key type of RSA, 4096 bits
> rsa 4k provides no real benefits over rsa 3k here; it is just slower
> for everyone, signing or verifying.
You can shorten the subkeys, but the root
On Wed, Feb 20, 2013 at 2:20 PM, Chí-Thanh Christopher Nguyễn
wrote:
> Rich Freeman schrieb:
>> 4. Non-fetchable - do not combine.
>
> I don't see a reason for fetch restriction, as long as a direct download
> link from upstream exists (via gitweb).
Agreed. You would only fetch-restrict a file
Rich Freeman schrieb:
> Probably makes sense to have a few tiers:
> 1. Free
> 2. Non-free, but redistributable
> 3. Non-free, nonredistributable, but fetchable (maybe combine with #2)
> 4. Non-fetchable - do not combine.
I don't see a reason for fetch restriction, as long as a direct download
Diego Elio Pettenò schrieb:
>> linux-firmware[non-free] <- the use flag to toggle between free and
>> non-free licenses.
>> linux-firmware-noredist <- This one is RESTRICT="fetch mirror"
> +1 — It requires some work from someone to actually split the stuff
> manually though, and there is at least o
Hi all,
I do not know whether this list is an appropriate place, so sorry if it
is not )
Recently I've wrote some little scripts that implement interface for
g-common type repositories of layman[1]. And I would ask those who is
interested to test them.
I've created two packages: g-common (interac
On 20/02/2013 19:43, Greg KH wrote:
> Really? What firmware files are that way, I just did a quick scan
> through the upstream linux-firmware.git tree and didn't see anything
> that would prevent Gentoo from doing this.
No, not really. Greg, please don't expect everybody's word here to be
the Pro
On Wed, Feb 20, 2013 at 07:25:14PM +0100, Peter Stuge wrote:
> Greg KH wrote:
> > > If there really are firmware blobs that are only available via git and
> > > which cannot be redistributed we might consider whether it makes sense
> > > to not support them entirely, or to force them to be masked.
> "RHJ" == Robin H Johnson writes:
RHJ> 2. Root key type of RSA, 4096 bits
rsa 4k provides no real benefits over rsa 3k here; it is just slower
for everyone, signing or verifying.
Cf, eg, http://www.nsa.gov/business/programs/elliptic_curve.shtml which
recommends rsa 3k for use with aes128/s
Greg KH wrote:
> > If there really are firmware blobs that are only available via git and
> > which cannot be redistributed we might consider whether it makes sense
> > to not support them entirely, or to force them to be masked.
>
> Did anyone actually consider the fact that there should not be
>
On Wed, Feb 20, 2013 at 11:03:47AM -0500, Rich Freeman wrote:
> On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò
> wrote:
> > On 20/02/2013 13:02, Rich Freeman wrote:
> >> I'm actually wondering if that makes sense with git when a specific
> >> commit is referenced, since everything is content-
On Wed, Feb 20, 2013 at 12:32 PM, Diego Elio Pettenò
wrote:
> That being the case, splitting them in multiple packages might indeed be
> a better option. Yes I know I'm the one pushing for using a single
> package — as long as it doesn't have licensing issues of course.
Yup, a combined package th
On 20/02/2013 18:28, Rich Freeman wrote:
> Agreed, especially if only 1-2 files are involved. If it is a bunch
> that could get unwieldy. Wasn't really thinking about that option.
That being the case, splitting them in multiple packages might indeed be
a better option. Yes I know I'm the one pus
On Wed, Feb 20, 2013 at 12:25 PM, Alec Warner wrote:
> A live SCM ebuild
> is not the only way to deploy something. If the user has to go
> download a blob out of linux-firmware's gitweb because we feel we
> cannot legally distribute the firmware, then that is what they have to
> do. If the user h
On Wed, Feb 20, 2013 at 9:17 AM, Rich Freeman wrote:
> On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner wrote:
>> On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge wrote:
>>>
>>> It makes no sense to make that unneccessarily difficult for users.
>>
>> I don't think fetch restriction is that annoying. Yo
On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner wrote:
> On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge wrote:
>>
>> It makes no sense to make that unneccessarily difficult for users.
>
> I don't think fetch restriction is that annoying. You could argue that
> we do it debian / ubuntu style where the
On Tue, Feb 19, 2013 at 10:32:13PM -0800, Alec Warner wrote:
> I agree that a smartcard is much better security vs a longer key. I
> don't think attackers targetting Gentoo are going to brute force the
> key. They are going to steal the key, trivially, by exploiting a 0-day
> in a crappy browser, o
On 20/02/2013 17:45, Alec Warner wrote:
> We could add something like PROPERTIES="network" to packages that
> require the network. I'm vaguely sure for instance, that some
> src_test() phases require a functioning network to work properly.
This has been proposed a bunch of times before, and I stil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2013 11:44 AM, Ulrich Mueller wrote:
>> On Wed, 20 Feb 2013, Rick \"Zero Chaos\" Farina wrote:
>
>> On 02/20/2013 02:55 AM, Ulrich Mueller wrote:
>
>> I am going to respond here because it makes the most sense to me.
>
>>> I mostly agre
On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge wrote:
> Diego Elio Pettenò wrote:
>> The policy is also because any ebuild relying on a network service
>> to work cannot be assured to work at any point in time
>
> While noble, I think it is a bit naïve. Reality is that many if not
> most ebuilds *an
> On Wed, 20 Feb 2013, Rick \"Zero Chaos\" Farina wrote:
> On 02/20/2013 02:55 AM, Ulrich Mueller wrote:
> I am going to respond here because it makes the most sense to me.
>> I mostly agree. However, there are not two, but three classes of
>> licenses for firmware images:
>>
>> 1. Free sof
On 20/02/2013 17:28, Peter Stuge wrote:
> This is just trying to be a bully and acting like a drama queen,
> which does nothing but make you look super silly, and that seems
> completely unneccessary.
>
> If you dislike something then you should express that in a more
> mature manner so that peopl
Diego Elio Pettenò wrote:
> The policy is also because any ebuild relying on a network service
> to work cannot be assured to work at any point in time
While noble, I think it is a bit naïve. Reality is that many if not
most ebuilds *anyway* rely on temporal things - such as a current
enough versi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2013 02:55 AM, Ulrich Mueller wrote:
I am going to respond here because it makes the most sense to me.
> I mostly agree. However, there are not two, but three classes of
> licenses for firmware images:
>
> 1. Free software
> 2. Non-free
On 20/02/2013 17:03, Rich Freeman wrote:
> Dropping
> or masking the packages doesn't fix the fact that they require a
> network service to install - it just makes it harder to install the
> package.
The reason why they are masked is because users who want to use a live
ebuild will acknowledge tha
On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò
wrote:
> On 20/02/2013 13:02, Rich Freeman wrote:
>> I'm actually wondering if that makes sense with git when a specific
>> commit is referenced, since everything is content-hashed anyway.
>> Perhaps we just need to confirm that git actually chec
On 20/02/2013 14:29, Chí-Thanh Christopher Nguyễn wrote:
> Problem is that the tarball cannot be redistributed by us. Now what?
Now you drop the firmwares that we can't distribute, and make the same
tarball — as for those firmware... hash them separately and
fetch-restrict them.
--
Diego Elio Pe
Tomáš Chvátal schrieb:
> 2013/2/20 Rich Freeman :
>> There is a current QA policy that anything using an scm to download
>> sources cannot be stabilized, because there is no way to verify the
>> manifest.
>>
>> I'm actually wondering if that makes sense with git when a specific
>> commit is referen
On 20/02/2013 13:02, Rich Freeman wrote:
> I'm actually wondering if that makes sense with git when a specific
> commit is referenced, since everything is content-hashed anyway.
> Perhaps we just need to confirm that git actually checks the hash.
No.
The policy is not _just_ because of the manife
2013/2/20 Rich Freeman :
> There is a current QA policy that anything using an scm to download
> sources cannot be stabilized, because there is no way to verify the
> manifest.
>
> I'm actually wondering if that makes sense with git when a specific
> commit is referenced, since everything is conten
On Tue, Feb 19, 2013 at 11:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> If all upstream has is a git tarball, what about git-snapshot builds?
> Use the git2 eclass and set a commit number, thus allowing testing and
> stabilization of a specific commit, but the checkout would be directly
> from ups
> On Wed, 20 Feb 2013, Alec Warner wrote:
> On Tue, Feb 19, 2013 at 11:55 PM, Ulrich Mueller wrote:
>> I mostly agree. However, there are not two, but three classes of
>> licenses for firmware images:
>>
>> 1. Free software
>> 2. Non-free, but can be redistributed
>> 3. Cannot be redistribut
Duncan wrote:
> Is it possible to tell git to only clone/pull specific files in a repo?
No.
//Peter
On Tue, Feb 19, 2013 at 11:55 PM, Ulrich Mueller wrote:
>> On Tue, 19 Feb 2013, Alec Warner wrote:
>
>> Lets not re-invent the wheel here:
>
>> Debian has free and non-free packages.
>> http://packages.debian.org/sid/firmware-linux
>
>> # free copyright
>> http://packages.debian.org/changelogs
39 matches
Mail list logo
