Ugh, sorry to follow up to myself, but I got a key part of this wrong.
Russ Allbery writes:
> At least based on my understanding of the theory, I think that mixing a
> backdoored entropy source with other entropy sources in a random number
> generator like Fortuna (which is based on the AES bloc
Gunnar Wolf writes:
> Russ Allbery dijo [Thu, Jun 12, 2014 at 07:08:40PM -0700]:
>> I would certainly hope that the mixing algorithm of any decent random
>> number source is better than just xor. And given that, I don't believe
>> the mathematics supports your assertion here. It's considerably
Russ Allbery dijo [Thu, Jun 12, 2014 at 07:08:40PM -0700]:
> > If you don't trust a hardware random number generator, you should not
> > xor it and another random number source together; after all, if you
> > believe the numbers coming out of the hardware random source are not
> > actually random,
Josh Triplett writes:
> If you don't trust a hardware random number generator, you should not
> xor it and another random number source together; after all, if you
> believe the numbers coming out of the hardware random source are not
> actually random, you might just as easily believe that they'
Theodore Ts'o wrote:
> On Thu, Jun 12, 2014 at 10:19:37AM -0700, Russ Allbery wrote:
> > I've never seen a convincing argument that the kernel /dev/random is
> > likely to be *less* secure than the hardware random number generator.
> > It's either more secure or the same level of security. Given t
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: 585 (new: 2)
Total number of packages offered up for adoption: 140 (new: 3)
Total number of packages request
Package: wnpp
Severity: wishlist
Owner: Markus Koschany
* Package name: lgeneral-data
Version : 1.0
Upstream Author : Steve McGuba, Markus Koschany
* URL : https://gitorious.org/lgeneral-data
* License : CC-BY-SA-3.0
Programming Lang: none
Description :
Hi Christoph,
On Donnerstag, 12. Juni 2014, Christoph Anton Mitterer wrote:
[many things]
both flashplugin-nonfree and torbrowser-launcher are (or will be) in contrib
(and thus not be part of Debian) for exactly those reasons you described. And
both rightfully belong to contrib, even though tor
On Thu, 12 Jun 2014 19:43:56 +0100
Wookey wrote:
> +++ Christoph Anton Mitterer [2014-06-12 01:06 +0200]:
> > - [c]debootstrap
> > I think they both default now to verify signatures (which is a good
> > thing)... but IIRC, debootstrap also defaults to not verify
> > anything... if the keyrings ar
Kurt Roeckx dixit:
>As far as I know, OpenBSD stopped using (A)RC4 for their random
>number generation for good reason, even though the function is
They stopped, but not for good reason. But you can also use the
new unlicenced algorithm they use, if you really feel like it,
it’s not bad either, j
Hi!
On Thu, 2014-06-12 at 21:19:06 +0200, Kurt Roeckx wrote:
> On Thu, Jun 12, 2014 at 10:23:58AM +0200, Thorsten Glaser wrote:
> > On Wed, 11 Jun 2014, Josh Triplett wrote:
> >
> > device is inferiour to the random devices on OpenBSD/MirBSD, so you
> > should seed the aRC4 state with additional
Hi!
On Thu, 2014-06-12 at 19:43:56 +0100, Wookey wrote:
> +++ Christoph Anton Mitterer [2014-06-12 01:06 +0200]:
> > - [c]debootstrap
> > I think they both default now to verify signatures (which is a good
> > thing)... but IIRC, debootstrap also defaults to not verify anything...
> > if the keyri
On Thu, Jun 12, 2014 at 10:23:58AM +0200, Thorsten Glaser wrote:
> On Wed, 11 Jun 2014, Josh Triplett wrote:
>
> device is inferiour to the random devices on OpenBSD/MirBSD, so you
> should seed the aRC4 state with additional random bytes:
As far as I know, OpenBSD stopped using (A)RC4 for their
+++ Christoph Anton Mitterer [2014-06-12 01:06 +0200]:
> - [c]debootstrap
> I think they both default now to verify signatures (which is a good
> thing)... but IIRC, debootstrap also defaults to not verify anything...
> if the keyrings aren't installed - admittedly this is unlikely... but
> possibl
]] Christoph Anton Mitterer
> Supplying the Debian Root CA to people not using Debian could have been
> easily done by a *single* site that uses a cert available in all
> browsers... which offers the Debian Root CA for secure and "trusted"
> download.
That's a nice theory. It does not align par
On Thu, Jun 12, 2014 at 10:19:37AM -0700, Russ Allbery wrote:
> I've never seen a convincing argument that the kernel /dev/random is
> likely to be *less* secure than the hardware random number generator.
> It's either more secure or the same level of security. Given that, it's a
> risk analysis,
Hi Chris,
You raise a lot of broad concerns under the header "holes in secure apt" which
I'm afraid does not much to get us closer to a more secure Debian. Not many
people will object that making Debian even more secure is a bad idea; it just
needs concrete action, not a large list of potential
On Thu, 2014-06-12 at 10:56 +0200, Jakub Wilk wrote:
> $ grep -r /soap.cgi lib/
> lib/debian/btssoap.rb:
> @server="http://#{host}:#{port}/cgi-bin/soap.cgi";
:-(
> bts(1) and reportbug(1) don't use HTTPS either, AFAICS.
:-(
> I noticed that http://bugs.debian.org/ started redirecting to
Josh Triplett writes:
> At least two reasons: because a random number source that doesn't
> require kernel privileges should not need to take the performance hit of
> going through the kernel,
I'm very dubious that this performance hit is substantial enough that it
should have an influence on ou
On Thu, 2014-06-12 at 10:30 +0200, Thorsten Glaser wrote:
> On Thu, 12 Jun 2014, Christoph Anton Mitterer wrote:
> > Anyone who believed in getting trusted sources might have been attacked
> > with forged packages, and even the plain build of such package might
> > have undermined users' security
On Thu, 2014-06-12 at 16:54 +0200, Christoph Anton Mitterer wrote:
> On Thu, 2014-06-12 at 08:58 +0200, Thijs Kinkhorst wrote:
> > If you want to discuss your plans to work on improving APT, you're more
> > on-topic at de...@lists.debian.org.
> I think this goes beyond
> just APT (even though APT
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will rep
On Thu, Jun 12, 2014 at 01:06:28AM +0200, Christoph Anton Mitterer wrote:
> In my opinion this is really some horrible bug... probably it could have
> been very easily found by others, and we have no idea whether it was
> exploited already or not.
Probably yes. Someone in the last ~11 years could
On Thu, 2014-06-12 at 08:58 +0200, Thijs Kinkhorst wrote:
> > Anyone who believed in getting trusted sources might have been attacked
> > with forged packages, and even the plain build of such package might
> > have undermined users' security integrity.
> >
> > The same is the case with all debian
On Thu, 2014-06-12 at 00:07 -0400, Joey Hess wrote:
> AAICS, #749795 talked about bringing this to the security team's
> attention, but they never seem to have been CCed.
Thanks for doing that now...
> So the security team may not be aware that a security hole in apt was
> recently fixed, that c
At Thu, 12 Jun 2014 08:36:16 +0200,
Matthias Urlichs wrote:
> That being said, sometimes you just need the binary equivalent of an
> uncompressible Lorem Ipsum text (dd if=/dev/urandom), but IMHO the kernel
> could (and should) provide a device for that.
If you just want to overwrite something wit
Package: wnpp
Severity: wishlist
Owner: Bruno Nova
* Package name: drmips
Version : 1.2.1
Upstream Author : Bruno Nova
* URL : https://bitbucket.org/brunonova/drmips/
* License : GPL
Programming Lang: Java
Description : Educational MIPS simulator - DrM
Martin Pitt writes ("Anyone using autopkgtest-xenlvm? Needs a maintainer or get
dropped"):
> If anyone is still using this, can you please get in contact with
> autopkgtest-de...@lists.alioth.debian.org and tell us the status of
> it? Would you like to continue maintaining/testing it?
For the avo
Le jeudi 12 juin 2014 à 11:41 +, Thorsten Glaser a écrit :
> Sébastien Villemot wrote:
>
> >The OpenLibm code derives from the FreeBSD msun implementation, which in turn
> […]
> >OpenLibm builds on Linux, and with little effort, should build on FreeBSD as
> >well. It builds with both, GCC and
Sébastien Villemot wrote:
>The OpenLibm code derives from the FreeBSD msun implementation, which in turn
[â¦]
>OpenLibm builds on Linux, and with little effort, should build on FreeBSD as
>well. It builds with both, GCC and clang. Although largely tested on x86, it
>also includes experimental su
Package: wnpp
Severity: wishlist
Owner: "Sébastien Villemot"
* Package name: openspecfun
Version : 0.3
Upstream Author : Julia development team
* URL : https://github.com/JuliaLang/openspecfun
* License : MIT, public domain
Programming Lang: C, Fortran
Desc
Package: wnpp
Severity: wishlist
Owner: "Sébastien Villemot"
* Package name: openlibm
Version : 0.3
Upstream Author : Julia development team
* URL : https://github.com/JuliaLang/openlibm
* License : BSD, MIT, ISC, public domain
Programming Lang: C, asm
Desc
* Christoph Anton Mitterer , 2014-06-12, 01:06:
- not really secure APT related: apt-listbugs
Not sure whether it uses https for getting bug infos...
$ grep -r /soap.cgi lib/
lib/debian/btssoap.rb:@server="http://#{host}:#{port}/cgi-bin/soap.cgi";
bts(1) and reportbug(1) don't use HTTP
On Thu, 12 Jun 2014, Christoph Anton Mitterer wrote:
> Anyone who believed in getting trusted sources might have been attacked
> with forged packages, and even the plain build of such package might
> have undermined users' security integrity.
Then I believe Debian itself may be undermined.
> The
* Thijs Kinkhorst , 2014-06-12, 08:58:
On Thu, June 12, 2014 01:06, Christoph Anton Mitterer wrote:
reopen 749795
stop
A better way would be to add more 'found' versions so the BTS version
tracking shows this bug as affecting stable.
Indeed. "reopen" throws away information about fixed vers
On Wed, 11 Jun 2014, Josh Triplett wrote:
> Any program desiring high-performance random numbers has a good reason to use
> RDRAND or RDSEED: they produce randomness *far* faster than the kernel, and
Yes, because SIGILL is so much faster…
Anyway. Even on systems supporting RDRAND, user space SHA
36 matches
Mail list logo
