Re: libbsd package
* Thorsten Glaser: > Any progress on the libbsd package, now that licence issues are out > of the way? IIRC, plans were to get it ready for all arches in lenny? We need a thread-safe version of something like arc4random as an element for various security patches (which will target etch). Shall we back-port libbsd as a whole, or should we just spin a separate library package? I'd also see a change that limits the number of bytes which is read from /dev/urandom (32 or fewer should be enough). I'm concerned about looping shell scripts darinign entropy from the pool at an unacceptably high rate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libbsd package
Florian Weimer dixit: >I'd also see a change that limits the number of bytes which is read from >/dev/urandom (32 or fewer should be enough). I'm concerned about >looping shell scripts darinign entropy from the pool at an unacceptably >high rate. For things like that, the OpenBSD and MirBSD kernels have /dev/arandom, which itself is also generated from arc4random(9). It's interesting that things like that haven't yet been picked up by other operating systems. (While arandom(4) only has 256 bytes (RC4) of internal state, and Linux random/urandom has 512, OpenBSD/MirBSD has 4096, the security of arandom increases the more users it has, and our kernel uses it internally quite heavily too.) bye, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 13:22⎜«neurodamage» since you're so good with it ☺ 13:28⎜«neurodamage:#cvs» i love you 13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libbsd package
* Thorsten Glaser: > Florian Weimer dixit: > >>I'd also see a change that limits the number of bytes which is read from >>/dev/urandom (32 or fewer should be enough). I'm concerned about >>looping shell scripts darinign entropy from the pool at an unacceptably >>high rate. > > For things like that, the OpenBSD and MirBSD kernels have /dev/arandom, > which itself is also generated from arc4random(9). It's interesting that > things like that haven't yet been picked up by other operating systems. While this is arguably the correct fix (it also addresses the threading issue), it is not something we can roll out in a security update because it's unlikely to find its way into upstream kernels. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libbsd package
Hi,
On Mon, 2008-07-07 at 13:08:53 +, Thorsten Glaser wrote:
> Dixi:
>
> >Any progress on the libbsd package, now that licence issues are out
> >of the way? IIRC, plans were to get it ready for all arches in lenny?
It took a bit more time than expected, but it's already there, as
you've already noticed. Replying to this just to explain some of the
decisions. And thanks for the suggestions, code and feedback!
> There are more problems with the libbsd package:
>
> • debian/copyright is incomplete (only mentions the FreeBSD files)
Yeah, fixed before uploading.
> • src/fgetln.c can never work correctly:
> │ size_t nread = 0;
> │ while (nread == 1) {
> Find attached a working fgetln.c used in MirMake and FreeWRT GNU/Linux
Ditto.
> • some files, like src/fmtcheck.c, can have BSDL clause 3 and 4 removed,
> see http://www.netbsd.org/changes/#2clause
That was already on the git tree.
> • the MD5 code from RSA DSI can be replaced by a Public Domain implemen-
> tation, I think I already sent it to… someone here I don’t remember.
> Attached (replaces md5c.c and md5.copyright)
Ditto.
> • I also attached the version of arc4random.c currently used by the mksh
> package for Debian, SuSE and Fedora/RHEL, as the FreeBSD version which
> is currently in libbsd trunk seems to be older
I had already imported a version from FreeBSD with the missing functions
some time ago.
> • I had already suggested including setmode/getmode, e.g. from the mksh
> source package (attached for convenience)
Didn't remember seeing that previous suggestion, but imported those
from FreeBSD as well before releasing 0.0.
> • In case someone is interested, I have a somewhat optimised strlcat(3)
> implementation… I'm building it with unifdef, generating 6 source files:
> ‣ unifdef -DHAVE_STRLCPY=0 -DHAVE_STRLCAT=1 strlfun.c >strlcpy.c
> ‣ unifdef -DHAVE_STRLCPY=1 -DHAVE_STRLCAT=0 strlfun.c >strlcat.c
> ‣ unifdef -DSTRXFRM strlfun.c >strxfrm.c
> ‣ unifdef -DHAVE_WCSLCPY=0 -DHAVE_WCSLCAT=1 wcslfun.c >wcslcpy.c
> ‣ unifdef -DHAVE_WCSLCPY=1 -DHAVE_WCSLCAT=0 wcslfun.c >wcslcat.c
> ‣ unifdef -DWCSXFRM wcslfun.c >wcsxfrm.c
> (of course, the strxfrm/wcsxfrm is only a stub, but okay according to
> the specs… strcoll becomes strcmp then)
I kept the current version from OpenBSD for simplicity.
thanks,
guillem
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libbsd package
Hi Florian, On Fri, 2008-07-18 at 17:28:30 +0200, Florian Weimer wrote: > * Thorsten Glaser: > > Any progress on the libbsd package, now that licence issues are out > > of the way? IIRC, plans were to get it ready for all arches in lenny? > > We need a thread-safe version of something like arc4random as an element > for various security patches (which will target etch). Shall we > back-port libbsd as a whole, or should we just spin a separate library > package? If the stable release team would be fine with introducing a new source package to stable then I guess the easiest is to just "backport". I think it most probably should build on etch w/o modifications. Otherwise from where were you thinking on generating the library package? > I'd also see a change that limits the number of bytes which is read from > /dev/urandom (32 or fewer should be enough). I'm concerned about > looping shell scripts darinign entropy from the pool at an unacceptably > high rate. I guess that'd be possible, but on what scenario would you see this happening? regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
