Hi.
On Thu, Jul 11, 2019 at 03:00:57PM +, Andy Smith wrote:
> On Thu, Jul 11, 2019 at 05:12:03PM +0300, Reco wrote:
> > On Thu, Jul 11, 2019 at 12:03:53PM +, Andy Smith wrote:
> > > I think the wiki article at
> > > https://wiki.debian.org/BoottimeEntropyStarvation really shows
On Thu, Jul 11, 2019 at 05:12:03PM +0300, Reco wrote:
> On Thu, Jul 11, 2019 at 12:03:53PM +, Andy Smith wrote:
> > I think the wiki article at
> > https://wiki.debian.org/BoottimeEntropyStarvation really shows that
> > currently there is no such consensus available, as every solution
> >
Hi.
On Thu, Jul 11, 2019 at 12:03:53PM +, Andy Smith wrote:
> Hi Greg,
>
> On Wed, Jul 10, 2019 at 09:03:16AM -0400, Greg Wooledge wrote:
> > The primary thing that's lacking is someone who actually knows all of
> > this stuff and can explain it properly. Everyone on this mailing
Hi Greg,
On Wed, Jul 10, 2019 at 09:03:16AM -0400, Greg Wooledge wrote:
> The primary thing that's lacking is someone who actually knows all of
> this stuff and can explain it properly. Everyone on this mailing list is
> grasping at straws that are lying around in various places, of different
>
On Mi, 10 iul 19, 07:39:54, Curt wrote:
> On 2019-07-08, Andy Smith wrote:
> > Hi Curt,
> >
> > On Mon, Jul 08, 2019 at 05:48:24PM -, Curt wrote:
> >> it "amounts to trusting that CPU manufacturer (perhaps with the
> >> insistence or mandate of a Nation State's intelligence or law
> >>
On Mi, 10 iul 19, 13:52:55, Curt wrote:
>
> His views shouldn't be "represented" at all. I thought it would be
> honest to have something brief, up front, and simple, in the notes
> themselves, like:
>
> For amd64 systems supporting the RDRAND instruction this issue is
> avoided by the Debian
On Wed 10 Jul 2019 at 13:52:55 (-), Curt wrote:
> On 2019-07-10, Andy Smith wrote:
>
> > Secondly, the reason I asked you what you would like done is that in
> > the message I replied to you said that the release notes were
> > something that users don't read. But your proposed solution is
On 2019-07-10, Greg Wooledge wrote:
>
> After that, it would be *wonderful* to have a well-written, comprehensive
> summary of the situation, and all of the available options, and their
> benefits and drawbacks, so users can choose the best one for their needs.
>
I agree.
--
"These findings
On 2019-07-10, Andy Smith wrote:
> Secondly, the reason I asked you what you would like done is that in
> the message I replied to you said that the release notes were
> something that users don't read. But your proposed solution is to
> put more things in the release notes.
I said users don't
On Wed, Jul 10, 2019 at 11:46:33AM +, Andy Smith wrote:
> In the release notes in the relevant section (5.1.4) the last
> paragraph is:
>
> See the wiki (https://wiki.debian.org/BoottimeEntropyStarvation)
> and DLange's overview of the issue
>
Hi.
On Wed, Jul 10, 2019 at 11:46:33AM +, Andy Smith wrote:
> > Further, I would like to know whether the patch will be "baked into the
> > kernel" or whether it can be toggled on and/or off at the *user's*
> > discretion. I don't remember being clear on this point after reading the
>
Hi Curt,
On Wed, Jul 10, 2019 at 09:26:31AM -, Curt wrote:
> On 2019-07-10, Andy Smith wrote:
> > But, let's say this use of RDRAND to supply boot-time entropy is as
> > serious as you argue. What would be your suggested configuration
>
> I would like Debian to make it clear in the
On 2019-07-10, Andy Smith wrote:
> Hi Curt,
>
> On Tue, Jul 09, 2019 at 07:59:53AM +, Curt wrote:
>> I think these reserves are relevant and pertinent to the patch
>> itself and should be revealed to the user, whom we cannot assume
>> or expect to follow the technical discussions of the
Hi Curt,
On Tue, Jul 09, 2019 at 07:59:53AM +, Curt wrote:
> I think these reserves are relevant and pertinent to the patch
> itself and should be revealed to the user, whom we cannot assume
> or expect to follow the technical discussions of the development
> team, in the release-notes for
On 2019-07-08, Andy Smith wrote:
> Hi Curt,
>
> On Mon, Jul 08, 2019 at 05:48:24PM -, Curt wrote:
>> it "amounts to trusting that CPU manufacturer (perhaps with the
>> insistence or mandate of a Nation State's intelligence or law
>> enforcement agencies) has not installed a hidden back door
On Ma, 09 iul 19, 18:19:22, David Wright wrote:
> On Tue 09 Jul 2019 at 10:50:01 (+0300), Andrei POPESCU wrote:
> >
> > I'm interested if the more recent kernel still uses ethX for the
> > wireless interface.
>
> Yes, with net.ifnames=0 I still get eth0 and eth1. I ran both options
> and
On Tue 09 Jul 2019 at 10:50:01 (+0300), Andrei POPESCU wrote:
> On Lu, 08 iul 19, 18:27:57, David Wright wrote:
> > On Mon 08 Jul 2019 at 19:21:37 (+0300), Andrei POPESCU wrote:
> > >
> > > [1] assuming ethernet cards are always named ethX and wireless cards are
> > > always named wlanX by the
On 2019-07-08, Andy Smith wrote:
> Hello,
>
> On Mon, Jul 08, 2019 at 04:18:28PM -, Curt wrote:
>> Well, looking at Ted Ts'o short patch, where he mentions the security
>> implications of the thing at some length, *twice*
>
> I think that some of Ted's stance might not be because Ted thinks
On Lu, 08 iul 19, 18:27:57, David Wright wrote:
> On Mon 08 Jul 2019 at 19:21:37 (+0300), Andrei POPESCU wrote:
> >
> > [1] assuming ethernet cards are always named ethX and wireless cards are
> > always named wlanX by the kernel. I might have had a wireless card that
> > came up as ethX, but
On Lu, 08 iul 19, 18:15:31, John Hasler wrote:
>
> More capitalist: eliminate copyrights and patents. Eliminating the
> capital gains tax break would also help.
The GPL relies on copyright. Reducing it to 10 years or so might be a
good compromise.
Kind regards,
Andrei
--
On Mon 08 Jul 2019 at 19:21:37 (+0300), Andrei POPESCU wrote:
> On Lu, 08 iul 19, 10:19:35, Curt wrote:
> >
> > I thought you were saying that
> > '/etc/udev/rules.d/70-persistent-net.rules' remains a valid mechanism
> > for defining interface names in Buster (fixed). But the release-notes
> >
On Mon, Jul 8, 2019 at 6:15 PM John Hasler wrote:
> Andy Smith writes:
> > To arrive
> > at a situation where the entirety of the CPU was open to inspection
> > would probably require a complete reworking of the modern economy,
> > i.e. make it less purely capitalist for a start.
>
> More
On Mon, 08 Jul 2019, Andrei POPESCU wrote:
> In my understanding what sysv-init does (crediting entropy over reboots)
> is not secure for various reasons.
Writes to /dev/urandom using dd *DOES NOT* and *NEVER HAS* credited any
entropy to the pool.
Which is what sysvinit (actually, initscripts)
Andy Smith writes:
> I think if we stopped using Intel and AMD then there would be some
> other near-monopoly manufacturer that would arise and embed
> unauditable blobs so we'd be in exactly the same position. To arrive
> at a situation where the entirety of the CPU was open to inspection
> would
Hi Nicholas,
On Mon, Jul 08, 2019 at 04:49:00PM -0500, Nicholas Geovanis wrote:
> On Mon, Jul 8, 2019 at 3:45 PM Andy Smith wrote:
> > Flash forward to 2017 and T'so himself wrote a patch to add a
> > configure option to allow RDRAND to be used early on to bootstrap
> > entropy. Thereafter it
On Mon, Jul 8, 2019 at 3:45 PM Andy Smith wrote:
> Hello,
>
> Flash forward to 2017 and T'so himself wrote a patch to add a
> configure option to allow RDRAND to be used early on to bootstrap
> entropy. Thereafter it would not be the exclusive source of entropy.
> That is what has been
Sorry for replying to myself.
On Lu, 08 iul 19, 23:50:02, Andrei POPESCU wrote:
>
> On the other hand Debian felt like from the moment I started with it and
home
> I was happy to be able to return to it once it gained
On Lu, 08 iul 19, 14:50:18, Gene Heskett wrote:
>
> But I must say even I was surprised by the near total bailout when I
> mentioned that it was raspian. Obviously in retrospect, there is bad
> blood?
Not from me. I was very much happy with Raspbian when I my Raspberry Pis
were still in use.
Hello,
On Mon, Jul 08, 2019 at 02:50:18PM -0400, Gene Heskett wrote:
> On Monday 08 July 2019 14:14:10 Andy Smith wrote:
> > On Mon, Jul 08, 2019 at 05:48:24PM -, Curt wrote:
> > > it "amounts to trusting that CPU manufacturer (perhaps with the
> > > insistence or mandate of a Nation State's
On Monday 08 July 2019 14:14:10 Andy Smith wrote:
> Hi Curt,
>
> On Mon, Jul 08, 2019 at 05:48:24PM -, Curt wrote:
> > it "amounts to trusting that CPU manufacturer (perhaps with the
> > insistence or mandate of a Nation State's intelligence or law
> > enforcement agencies) has not installed
Hi Curt,
On Mon, Jul 08, 2019 at 05:48:24PM -, Curt wrote:
> it "amounts to trusting that CPU manufacturer (perhaps with the
> insistence or mandate of a Nation State's intelligence or law
> enforcement agencies) has not installed a hidden back door to
> compromise the CPU's random number
On 2019-07-08, Andrei POPESCU wrote:
>
>> Well, at the very least people should be informed who is likely to be
>> affected by the bug
>
> In my understanding a lot of daemons are affected. Would it make sense
> to (try to) list them all?
Well, then, you should make that explicit, viz. that
Hello,
On Mon, Jul 08, 2019 at 04:18:28PM -, Curt wrote:
> Well, looking at Ted Ts'o short patch, where he mentions the security
> implications of the thing at some length, *twice*
I think that some of Ted's stance might not be because Ted thinks it
is dangerous but because there has been in
On Lu, 08 iul 19, 10:19:35, Curt wrote:
>
> I thought you were saying that
> '/etc/udev/rules.d/70-persistent-net.rules' remains a valid mechanism
> for defining interface names in Buster (fixed). But the release-notes
> (hmm, I think they've been modified since I last looked and now state
> that
On 2019-07-08, Greg Wooledge wrote:
>
> I don't have any opinions at this time about the trustworthiness of
> various x86 CPU RDRAND instructions, but...
Well, looking at Ted Ts'o short patch, where he mentions the security
implications of the thing at some length, *twice*---once in the "intro"
Hello,
On Mon, Jul 08, 2019 at 02:40:16PM -, Curt wrote:
> But as an innate altruist (just kidding), I'm wondering whether the
> regular user is aware of the implications of all this. What about people
> in Nation States ... Well, you get the idea.
Thing is, if you can't trust that your
Hi.
On Mon, Jul 08, 2019 at 05:57:49PM +0200, Thomas Schmitt wrote:
> Hi,
>
> Curt quoted:
> > This will prevent getrandom(2) from blocking, if there is a
> > willingness to trust the CPU manufacturer.
> > Signed-off-by: Theodore Ts'o
>
> Apropos trusting strange allies:
>
> #
Hi,
Curt quoted:
> This will prevent getrandom(2) from blocking, if there is a
> willingness to trust the CPU manufacturer.
> Signed-off-by: Theodore Ts'o
Apropos trusting strange allies:
# mount debian-10.0.0-amd64-netinst.iso /mnt/iso
mount: /dev/loop0 is write-protected, mounting
On Mon, Jul 08, 2019 at 02:40:16PM -, Curt wrote:
> Earlier I thought bullseye was some sort of idiom for Buster going live.
> Color me ignorant.
Bullseye will be the next version of Debian after buster, probably in
2-3 years. Cue the confusion about two similar-looking release names
back
On 2019-07-08, Andrei POPESCU wrote:
>
> The timing was also not very good for the buster release cycle.
> Hopefully this will be sorted out properly in time for bullseye.
Earlier I thought bullseye was some sort of idiom for Buster going live.
Color me ignorant.
But concerning the currently
On 2019-07-08, Andrei POPESCU wrote:
>
> The timing was also not very good for the buster release cycle.
> Hopefully this will be sorted out properly in time for bullseye.
That would be great. Then if they could resuscitate ecryptfs-utils
I would be a happy camper.
;-)
> Kind regards,
> Andrei
On 2019-07-08, Andrei POPESCU wrote:
>
>
> On Lu, 08 iul 19, 09:44:51, Curt wrote:
>> On 2019-07-08, Andrei POPESCU wrote:
>> >
>> > On Lu, 08 iul 19, 09:06:33, Curt wrote:
>> >> On 2019-07-08, Andrei POPESCU wrote:
>> >> >
>> >> > This was fixed before the release.
>> >> What?
>> >
>> > Is
On Lu, 08 iul 19, 09:01:36, Curt wrote:
> On 2019-07-08, Andrei POPESCU wrote:
> >
> >> Wow. Another reason to love systemd :-(
> >
> > Not clear to me why you are blaming systemd here.
>
> Because systemd is to blame (at least in the opinion of some people in the
> know, like Stefan Frisch, for
On Lu, 08 iul 19, 09:44:51, Curt wrote:
> On 2019-07-08, Andrei POPESCU wrote:
> >
> > On Lu, 08 iul 19, 09:06:33, Curt wrote:
> >> On 2019-07-08, Andrei POPESCU wrote:
> >> >
> >> > This was fixed before the release.
>
> >> What?
> >
> > Is there something wrong with the current wording?
>
>
On 2019-07-08, Andrei POPESCU wrote:
>
> On Lu, 08 iul 19, 09:06:33, Curt wrote:
>> On 2019-07-08, Andrei POPESCU wrote:
>> >
>> > This was fixed before the release.
>> What?
>
> Is there something wrong with the current wording?
I guess, as I thought I was referring to the release-notes,
On Lu, 08 iul 19, 09:06:33, Curt wrote:
> On 2019-07-08, Andrei POPESCU wrote:
> >
> > This was fixed before the release.
>
> What?
Is there something wrong with the current wording?
> > You are aware that the Release Notes are work in progress as long as the
> > corresponding Debian release
On 2019-07-08, Andrei POPESCU wrote:
>
> This was fixed before the release.
What?
> You are aware that the Release Notes are work in progress as long as the
> corresponding Debian release is still in testing, right?
>
How will the mistakes be fixed if no one points them out?
>> misleading (if
On 2019-07-08, Andrei POPESCU wrote:
>
>> Wow. Another reason to love systemd :-(
>
> Not clear to me why you are blaming systemd here.
>
Because systemd is to blame (at least in the opinion of some people in the
know, like Stefan Frisch, for instance):
On Lu, 08 iul 19, 08:40:06, Curt wrote:
>
> I guess I would not be affected because I'm not running an entropy-hungry
> service (or any services at all), but what a PITA to have gone on this wild
> goose chase to finally find that out (if true). These release-notes for
> Buster,
> as they stand,
On 2019-07-07, Andrei POPESCU wrote:
>
> It sounds a lot like this issue:
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#entropy-starvation
Due to systemd needing entropy during boot and the kernel treating such calls
as blocking when available entropy is
On Du, 07 iul 19, 12:44:30, Nicholas Geovanis wrote:
> Wow. Another reason to love systemd :-(
Not clear to me why you are blaming systemd here.
In my understanding what sysv-init does (crediting entropy over reboots)
is not secure for various reasons.
> Another reason to perform fresh
On Sunday 07 July 2019 10:45:33 Tixy wrote:
> On Sun, 2019-07-07 at 10:29 -0400, Gene Heskett wrote:
> > Greetings;
> >
> > Maybe I shouldn't publish this, but I found a fix for the no ssh on
> > reboot till you start it from it's own keyboard. It bypasse
gt; > Greetings;
> > >
> > > Maybe I shouldn't publish this, but I found a fix for the no ssh on
> > > reboot till you start it from it's own keyboard. It bypasses
> > > someones
> > > paranoia. If interested, pm me.
> >
> > Why not just let us
On Du, 07 iul 19, 15:45:33, Tixy wrote:
> On Sun, 2019-07-07 at 10:29 -0400, Gene Heskett wrote:
> > Greetings;
> >
> > Maybe I shouldn't publish this, but I found a fix for the no ssh on
> > reboot till you start it from it's own keyboard. It bypasses
> > someo
On Sun, 2019-07-07 at 10:29 -0400, Gene Heskett wrote:
> Greetings;
>
> Maybe I shouldn't publish this, but I found a fix for the no ssh on
> reboot till you start it from it's own keyboard. It bypasses
> someones
> paranoia. If interested, pm me.
Why not just let us know
Greetings;
Maybe I shouldn't publish this, but I found a fix for the no ssh on
reboot till you start it from it's own keyboard. It bypasses someones
paranoia. If interested, pm me.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and
56 matches
Mail list logo
