On Thu, 28 Feb 2019 at 17:53:37 -0500, Reinhard Tartler wrote:
> Upstream doesn't appear to be willing to upgrade to a new version (quote from
> the bug above "[...] I really don't want to [...]". Looking at how this
> package
> is using the vendored library, it seems openshift/imagebuilder is usi
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 1393 (new: 1)
Total number of packages offered up for adoption: 165 (new: 3)
Total number of packages reques
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
* Package name: golang-github-openshift-imagebuilder
Version : 1.0+git20190212.3682349-1
Upstream Author : OpenShift
* URL : https://github.com/openshift/imagebuilder
* License : Apache-2.0
Programmin
> "Thorsten" == Thorsten Glaser writes:
Thorsten> It’s not about what we feed to the kernel, but about the
Thorsten> property of it distributing the input evenly across the
Thorsten> output. The basic tenet here is that, if I have 128 bytes
Thorsten> of random input from the s
Ben Hutchings dixit:
>On Thu, 2019-02-28 at 14:52 +, Ian Jackson wrote:
>>Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
>>> • during postinst, creates a 128-byte random seed file in /
>>
>>Can you confirm that this is done with data from
>>getrandom(,,GRND_RANDOM) ? (Presumably wi
Sebastian Andrzej Siewior dixit:
>so I have one older box that suffers from that. I installed haveged and
>seemed to went away:
I tried that, after the suggestion to use haveged went up, but…
>As far as I understand, it would reach the "init done" state before
>systemd took over, right?
… this
> "Ben" == Ben Hutchings writes:
>> If the seed > files used in two different boots are somewhat
>> correlated, and the > entropy estimation doesn't account for
>> that, the output of /dev/random > may also be somewhat correlated
>> between the boots, which is not > supposed t
On Thu, 2019-02-28 at 14:52 +, Ian Jackson wrote:
[...]
> > to initialise a stretching RNG (arc4random)
>
> Why are you feeding this through a separate hashing function rather
> than letting the kernel PRNG's hasher do it ? I am seriously
> unconvinced that arc4random is a good idea her
On Thu, 2019-02-28 at 11:56 +, Ian Jackson wrote:
> Ben Hutchings writes ("Re: FYI/RFC: early-rng-init-tools"):
> > On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
> > > Generally you don't ever
> > > need to use /dev/random instead of /dev/urandom unless you make
> > > assumptions about
Hi Jérémy,
On 28-02-2019 16:05, Jérémy Lal wrote:
> the documentations:
> https://release.debian.org/buster/freeze_policy.html
> https://www.debian.org/doc/manuals/developers-reference/ch05.html#bug-security
>
> leave me unsettled about what to do during freeze w.r.t. security
> uploads in testi
Hi,
the documentations:
https://release.debian.org/buster/freeze_policy.html
https://www.debian.org/doc/manuals/developers-reference/ch05.html#bug-security
leave me unsettled about what to do during freeze w.r.t. security uploads
in testing.
(for a known and upstream-fixed CVE):
- should i just g
Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
> • during postinst, creates a 128-byte random seed file in /
Can you confirm that this is done with data from
getrandom(,,GRND_RANDOM) ? (Presumably with GRND_NONBLOCK too.)
> – after the root filesystem is read-write,
> ‣ reads fr
> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: FYI/RFC: early-rng-init-tools"):
>> Ben Hutchings writes: >[Someone:] >> The
>> additional entropy gathered is for extra safety; it is not >>
>> *depended* on for basic security assumptions. > [...] It is,
>>
Ben Hutchings writes ("Re: FYI/RFC: early-rng-init-tools"):
> On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
> > Generally you don't ever
> > need to use /dev/random instead of /dev/urandom unless you make
> > assumptions about cryptography failing.
>
> I think I agree with that, but there
Sam Hartman writes ("Re: FYI/RFC: early-rng-init-tools"):
> Ben Hutchings writes:
> >[Someone:]
> >> The additional entropy gathered is for extra safety; it is not
> >> *depended* on for basic security assumptions.
> > [...]
> It is, because the the kernel is told to treat it as providing
> > a c
15 matches
Mail list logo