Bug#764399: ITA: makefs -- create a cd9660 or ffs file system image from a directory tree
retitle 764399 ITA: makefs -- create a cd9660 or ffs file system image from a directory tree owner 764399 ! thanks Hi, Christoph Egger and I agree that as GNU/kFreeBSD Maintainers we should adopt this package. It is required by debian-installer to build the d-i netboot images for kfreebsd. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
Hi, So from https://github.com/zfsonlinux/pkg-spl we have: > Package: libnvpair1 > Package: libnvpair1-dbg > Package: libuutil1 > Package: libuutil1-dbg > Package: libzfs1 > Package: libzfs1-dbg > Package: libzfs-dev > Package: libzpool1 > Package: libzpool1-dbg > Package: zfs-dkms > Package: zfs-initramfs > Package: zfsutils > Package: zfsutils-dbg And in the existing zfsutils package, currently only built for kfreebsd-any, we have: > Package: libnvpair1 > Package: libnvpair1-udeb > Package: libumem1 > Package: libumem1-udeb > Package: libuutil1 > Package: libuutil1-udeb > Package: libzfs1 > Package: libzfs1-udeb > Package: libzpool1 > Package: libzpool1-udeb > Package: zfsutils > Package: zfsutils-udeb With such an overlap implied by that, and knowing it all originated from a common codebase at some time, I really hope it can be merged back into a common package built for kfreebsd-any and linux-any. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538c7e03.9090...@pyro.eu.org
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
This is good to see already :) I expect it builds fine on GNU/Linux, with GCC and Clang, unless hardening options are used, then these warnings would be treated as errors: > In file included from md5/md5_locl.h:98:0, > from md5/md5_dgst.c:60: > md5/md5_dgst.c: In function 'md5_block_data_order': > ./md32_common.h:237:66: warning: right-hand operand of comma expression has > no effect [-Wunused-value] > # define HOST_c2l(c,l) ((l)=*((const unsigned int *)(c)), (c)+=4, l) > ^ > md5/md5_dgst.c:107:2: note: in expansion of macro 'HOST_c2l' > HOST_c2l(data,l); X( 0)=l; HOST_c2l(data,l); X( 1)=l; > ^ > ./md32_common.h:213:41: warning: right-hand operand of comma expression has > no effect [-Wunused-value] > l|=(((unsigned long)(*((c)++)))), \ > ^ > sha/sha256.c:245:3: note: in expansion of macro 'HOST_c2l' >HOST_c2l(data,l); T1 = X[0] = l; ROUND_00_15(0,a,b,c,d,e,f,g,h); >^ We'd want to configure with --disable-silent-rules, if debhelper scripts don't already do that. Compiling on GNU/kFreeBSD is possible (and potentially GNU/Hurd) but requires the attached patch *and* a solution for getentropy: 1. try to use getentropy_linux.c - but would have to disable use of Linux-specific sysctls and headers; it is dangerous to rely on only /dev/random, so we should implement replacement sysctls to use on FreeBSD - that could be a bit messy 2. create a new getentropy_freebsd.c - but seems silly as FreeBSD itself does not need it (see solution 3); also does not help GNU/Hurd 3. (my preference) link with libbsd, which already provides a arc4random_buf and so getentropy is not needed at all - WARNING: the libbsd arc4random implementation still uses RC4 at the moment (as on FreeBSD), but OpenBSD has already changed it to use ChaCha20 (see Bug #747671); we'd also want to make sure libbsd's entropy gathering is at least as robust as in getentropy_linux.c Regards, -- Steven Chamberlain ste...@pyro.eu.org --- configure.orig 2014-07-11 18:42:02.0 +0100 +++ configure 2014-07-12 01:26:15.064409115 +0100 @@ -2915,7 +2915,7 @@ TARGET_OS=darwin; LDFLAGS="$LDFLAGS -Qunused-arguments" ;; - *linux*) + *linux* | *gnu*) TARGET_OS=linux; CFLAGS="$CFLAGS -D_BSD_SOURCE -D_POSIX_SOURCE -D_GNU_SOURCE" ;;
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On Jul 12, Toni Mueller wrote: > On Sat, Jul 12, 2014 at 07:43:44AM +0200, Marco d'Itri wrote: > > On Jul 12, Toni Mueller wrote: > > > * Package name: libressl > > I am highly doubtful at best. > > in which respect, and why? I think some people are jumping ahead to "oh no! we're replacing OpenSSL?". That's something to be have some rough plan for in case we eventually want to do that. But for now I don't think it's a reason not to package it or even allow it into sid/testing. > > What are your plans exactly? > > My plan is to first build the package(s) and upload to experimental, so > people can start to play with it. It is definitely an interesting piece of software, with some different design choices being made here and there. It even adds some new features (new ciphers and elliptic curves for example) and the utilities are useful standalone (such as for an SSL CA). People can start to play around with it and maybe to try to rebuild packages against it locally. It couldn't be a drop-in replacement for OpenSSL's libssl and libcrypto because the ABI will differ. The source API is being kept as similar as possible so in theory: > Packages currently build-depending on openssl should be able to > build-depend on "openssl-dev | libressl-dev". that sounds like it should just work. Or otherwise, it could reveal if a package uses some 'unsafe' part of the API that OpenBSD has removed during their cleanup. Any incompatibilities or run-time differences are likely interesting to both SSL libraries as it could indicate a bug somewhere. Probably only a minority of people would want to rebuild many packages on their system against LibreSSL. But having it packaged, and co-installable helps people who want to do this. Similarly there is support in the Exim packaging to rebuild with OpenSSL instead of GnuTLS. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712140150.ga15...@squeeze.pyro.eu.org
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On 12/07/14 02:09, Steven Chamberlain wrote: > [...] these warnings would be treated as errors: > >> > In file included from md5/md5_locl.h:98:0, >> > from md5/md5_dgst.c:60: >> > md5/md5_dgst.c: In function 'md5_block_data_order': >> > ./md32_common.h:237:66: warning: right-hand operand of comma expression >> > has no effect [-Wunused-value] >> > # define HOST_c2l(c,l) ((l)=*((const unsigned int *)(c)), (c)+=4, l) >> > ^ A new upstream release LibreSSL 2.0.1 already addressed that: basically stop using -Werror in the portable library because many compilers have warnings that OpenBSD's compiler does not, and I guess they did not think the warnings legitimate or worth the effort of 'fixing' right now. This new version brings in many small changes from the still-ongoing cleanup. ABI versions bumped to libcrypto 30.0.0 and libssl 27.0.0. AFAICT only private_RC4_set_key was removed, and ssl_version_string added to the respective libraries' exported symbols. Am I right in thinking Debian would not bump its own SONAME if there were unimportant ABI changes, like these seem to be? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c2ef58.4050...@pyro.eu.org
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On 12/07/14 12:53, Toni Mueller wrote: > my intention is to package this stuff so one can have both openssl and > libressl installed in parallel. libressl currently has libraries with > these sonames: > > libssl.so.26 > libcrypto.so.29 If the ABI is already different, there's no need for the library names to exactly match what the Debian OpenSSL package has or what OpenBSD uses? Actually I think you should avoid it, to avoid any confusion. Perhaps use libssl-openbsd.so.26, libcrypto-openbsd.so.30 just like we did in src:freebsd-libs? Or pick anything else that sounds better. The "openssl" binary built by LibreSSL sources will also need to be renamed, if they're to be co-installable. To "libressl" I presume? AFAIK the command-line apps have not changed significantly (except bugfixes) so could be a drop-in replacement someday (much easier than switching libraries). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c30523.4060...@pyro.eu.org
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On 14/07/14 21:08, Toni Mueller wrote: >> > You forget one of the big problems with OpenSSL that LibreSSL doesn't >> > fix: the license. > Granted. Due to the amount of inherited code, it can't. We'll see how > things evolve as the amount of inherited code will dwindle. So, merely as a result of the licensing, we could have a fascinating situation whereby: * BSD-licensed software contemplates switching from OpenSSL to LibreSSL * GNU-licensed software keeps using OpenSSL with license exception, or maybe someday switches to GnuTLS So, this reduces the amount of software that could potentially switch from OpenSSL from LibreSSL. And since BSD and GNU software are unable to link against each other, it reduces the likelihood that something will indirectly link against OpenSSL and LibreSSL at the same time (the situation Russ Allbery described). So actually I think this simplifies things. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c43d49.6070...@pyro.eu.org
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On 16/07/14 03:06, Paul Tagliamonte wrote: > I didn't see this yet in the thread, so: > https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux What's most interesting is that someone spent such effort to look for this; that there are so many eyes now on both the original OpenSSL and the new LibreSSL code. Both projects ought to benefit from this. This was a real, but totally contrived issue with many preconditions: * initial 'grandparent' process initialises LibreSSL's PRNG, then forks * first-forked process does not use the PRNG yet, but forks again * grandparent uses the PRNG for things and then exits, freeing up the pid to be re-used * second-forked 'grandchild' process might coincidentally get the same pid as its grandparent * grandchild uses the PRNG for things; LibreSSL would not realise it has forked if the pid is the same, so does not reseed - PRNG output would be repeated from what the grandparent got before it exited - possibly having security impact The other major concern was about scary entropy-gathering code, implemented in LibreSSL Portable for Linux as a last resort for when /dev/urandom can't be read. I agree that it's too risky, or: too difficult to prove safe and robust in any conceivable situation. Debian's major OpenSSL bug was able to happen undetected for a while out of similar circumstances. A compile-time ifdef already allows to disable this fallback code and raise SIGKILL instead, crashing the calling process. As part of the LibreSSL port to GNU/kFreeBSD and Hurd I would actually have asked that we do this anyway in Debian, at least for those platforms. It seems extreme, but the point is that something must be wrong on the system if we get to the fallback code - /dev/urandom missing from a chroot, or fd's exhausted, and the kernel not having a reliable sysctl interface like OpenBSD's to get random bytes in the first place. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
(This may seem a little off-topic for the ITP but please bear with me...) On 16/07/14 21:13, Guillem Jover wrote: > kFreeBSD does have a supported sysctl for this: CTL_KERN KERN_ARND. > (As does NetBSD which has two, KERN_URND and KERN_ARND.) Actually yes, we would certainly want to use that. But is there any conceivable way it could fail? (sysctl calls can return an error code). What could we do then? We'd need to figure this out if we want the prospective libressl package to build on GNU/kFreeBSD on Hurd. Currently it won't build, because it needs either a kernel-specific getentropy implementation, or arc4random. libbsd's arc4random.c, I'm guessing was based on older OpenSSH Portable sources. If reading /dev/urandom fails, it uses only gettimeofday, getpid, and uninitialised bytes from the stack (as a seed to the PRNG). LibreSSL Portable on Linux has the new, scary fallback mechanism instead, more comprehensive, but I honestly don't like that approach. It's too difficult to estimate how much entropy it could really gather, or potential failure cases. And we wouldn't even know when the fallback was being used. Native OpenBSD would actually raise SIGKILL if their sysctl fails. (Their cvsweb is down - quoting inline from arc4random.c instead) : > _rs_stir(void) > [...] > if (getentropy(rnd, sizeof rnd) == -1) > raise(SIGKILL); libevent's arc4stir is different again; it's defined to return an int, with -1 indicating a failure of all attempts to seed: * from /dev/urandom * from /proc/sys/kernel/random/uuid * using a kernel-specific sysctl These arc4random implementations also differ in which stream cipher they use also (RC4 originally, ChaCha20 in newer OpenBSD code). As a result of all this mess, I think we should be looking to converge on a single arc4random implementation, in a place such as libbsd, but make sure it is up to the task first. If arc4random is available and LDFLAGS include -lbsd, LibreSSL Portable will actually use it instead of the bundled implementation. I'm guessing OpenSSH Portable would do this too (I can see it being tested for by ./configure in the buildd log). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c6e74d.8080...@pyro.eu.org
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Oh, and note that OpenSSH Portable uses RAND_bytes from libssl to seed its arc4random implementation. So AFAICT if you were to link OpenSSH Portable against LibreSSL Portable, it would get really crazy: /dev/urandom or sysctl or scary fallback -> LibreSSL Portable getentropy -> LibreSSL Portable arc4random.c (ChaCha-20) -> LibreSSL RAND_bytes -> OpenSSH Portable arc4random.c (ChaCha-20) -> OpenSSH with the stream cipher, seeding and stirring all happening twice. So I really like the idea of both getting an arc4random implementation from one place, such as libbsd. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c6ec32.9000...@pyro.eu.org
Bug#754513: Questions from upstream
Hi Brent, Thank you very much for your input here. On 21/07/14 13:10, Brent Cook wrote: > Also, please do not replace arc4random in libressl. We'll have to figure > out what to do about the circular dependency with openssh OK, let's see what the OpenSSH Portable team comes up with... Having embedded copies of arc4random.c in different packages though (libressl, openssh, libevent, libbsd) is not great. It would be nice to someday package it into a re-usable library for all of Debian to use, and for ensuring it always stays up-to-date with upstream. (The one in LibreSSL Portable is currently the most up-to-date; I realise other/older versions of it are unsafe for some use cases). > replacing > with the version from libbsd is really not the way to go at the moment Agreed, there are serious problems with the arc4random in libbsd at the moment (I'm looking at our options to fix this). But if we could someday split out arc4random, then libbsd would seem like a good place to put it. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53cd0831.9080...@pyro.eu.org
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/14 15:13, Turbo Fredriksson wrote: > It's very flattering that people thought my stuff was good enough to accept > without further review, > but it's also a bit frightening - I'm good, but not THAT good (as we could > see :). ISTR it was committed to master by mistake? Then reverted, but when Christian Perrier originally did this he rewrote git history; Joey Hess corrected that in the VCS, but Christian's next upload reintroduced it all from his working copy. Or something like that. The actually useful bits for Linux were later reverted by KiBi due to d-i build issues, but the other changes (including some that are problematic for kFreeBSD) are still there. Perhaps I could undo Turbo's changes in master, and we can later carefully review, clean up and reintroduce changes ZoL really needs? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5310f6e7.4000...@pyro.eu.org
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 02/03/14 12:19, Turbo Fredriksson wrote: > Might I suggest that the reason is that these is _completely_ different > implementation, with > absolutly no common code? Right, so conversely, zfs-linux shares a lot of code already with zfsutils and it makes no sense for them to be packaged separately or compete over namespace? > if the FTP maintainers [...] say that this is not acceptable, > then we'll rename it, without any bitching or > whining or expressing opinions that we can't backup with facts. > Basically, their ruling is law. Your opinion is just that - your opinion and > bear no weight at this > moment. It actually seemed to be an offer for collaboration with you, but I don't see that working so well now. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531356ba.5090...@pyro.eu.org
