Re: Bug#706414: CVE-2013-3266: Insufficient input validation in the NFS server

* Christoph Egger: > Hi! > > Steven Chamberlain writes: >> tags 706414 + pending >> thanks >> >> I've applied upstream's patch in SVN, I'm running it now on my NFS >> server and seems okay. >> >> Christoph, would you be able to do an upload of this to unstable please? > > I'm building right now.

Re: Bug#706414: CVE-2013-3266: Insufficient input validation in the NFS server

* Christoph Egger: > Packages will be in people.d.o:~christoph soon (or shall I upload to > security directly? Looks good. Please upload to security-master directly. You have to rebuild with -sa, though, so that the upstream tarball is included in the upload. -- To UNSUBSCRIBE, email to debi

Bug#706414: CVE-2013-3266: Insufficient input validation in the NFS server

* Steven Chamberlain: > On 01/05/13 15:20, Christoph Egger wrote: >> Florian Weimer writes: >>> Looks good. Please upload to security-master directly. You have to >>> rebuild with -sa, though, so that the upstream tarball is included in >>> the upload. >

Re: Bug#706414: CVE-2013-3266: Insufficient input validation in the NFS server

* Steven Chamberlain: > Hi, > > On 22/05/13 19:46, Florian Weimer wrote: >> Sorry for the delay. I'm taking care of this now. > > Thank you for the DSA. > > I notice a problem though when this was (I think - I'm unsure of the > security team's process

Re: Bug#706414: CVE-2013-3266: Insufficient input validation in the NFS server

* Adam D. Barratt: > On Fri, 2013-05-24 at 22:20 +0200, Florian Weimer wrote: >> * Steven Chamberlain: >> > I notice a problem though when this was (I think - I'm unsure of the >> > security team's processes here) copied to the main archive, probably so &

NetBSD port dead?

Is the NetBSD port dead? And if it's not, what's the name of the kernel packages? Does the port use GNU libc? (Please Cc: me on replies as I'm not subscribed to the mailing list.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New user - Some problems (emacs, sbcl)

* Cyril Brulebois: > About the sbcl package, I never work on bootstrapping, but I'm willing > to try that soon. Can SBCL still be compiled with CLISP? In that case, it's not a real bootstrapping exercise, and it might be easier to go that route. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] w

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 w

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 unacceptabl

Re: libbsd package

* Guillem Jover: > 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 > pa

Re: ZFS on kFreeBSD

* Jerome Warnier: > While the current status of Debian GNU/kFreeBSD is interesting, I was > quite disappointed there is no ZFS support in it (at least any related > tools). > Any plans to enable this support? Is ZFS producton-ready? On Solaris, Sun recommends to reformat and restore from backup

Re: ZFS on kFreeBSD

* Florian Weimer: > * Jerome Warnier: > >> While the current status of Debian GNU/kFreeBSD is interesting, I was >> quite disappointed there is no ZFS support in it (at least any related >> tools). >> Any plans to enable this support? > > Is ZFS producton-r

Bug#559107: weaknesses in BSD PRNG algorithms

* Petr Salinger: > If I understand it correctly, the security problem is > "it allows remote attackers to guess sensitive values such as IP > fragmentation IDs by observing a sequence of previously generated > values". > By default, the next_value is previous_value+1, i.e. unsecure at all. > It ca

Bug#567939: No way to display routing table

Package: freebsd-net-tools Version: 8.0-2 Severity: important Both netstat and route fail on squeeze with a 7.2 kernel ("route: writing to routing socket: Invalid argument" and "netstat: kvm_read: Bad address"). I think you need to package kernel-specific versions of these tools. -- To UNSUBS

Re: Bug#567939: No way to display routing table

* Axel Beckert: >> Both netstat and route fail on squeeze with a 7.2 kernel ("route: >> writing to routing socket: Invalid argument" and "netstat: kvm_read: >> Bad address"). >> >> I think you need to package kernel-specific versions of these tools. > > They are there. route is just a (currently

Re: DSO linking changes for wheezy

* Roland McGrath: >> I can't see why you think --as-needed is fundamentally wrong or unnecessary. > > It is fundamentally wrong because -lfoo means I demand that the > initializers of libfoo.so run, whether or not I called anything in it. So it's more like static linking. 8-) IMHO, the current d

Re: [Stretch] Status for architecture qualification

> In other words, i don't think a s390x box will ever just die. I'm sure “death” encompasses all events which might lead Debian to lose access to relevant hardware. It's not just about faults with a piece of equipment.

Re: [Stretch] Status for architecture qualification

* Lennart Sorensen: > There are a lot of 32bit powerpc chips still going into embedded systems > being built today. They are not going away anytime soon. Do they implement the ISA required by the existing Debian port?

Re: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Petter Reinholdtsen: > Something like this should work, I guess: > > if [ ! -f /etc/hostid ]; then >if [ -e /sys/class/dmi/id/product_uuid ]; then >sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid) >else > dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null >

Re: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Petter Reinholdtsen: > [Florian Weimer] >> That's not very different from /etc/machine-id, isn't it? > > Ah, thank you very much for bringing this systemd setting to my > attention. I was not aware of it. > > I agree that it seem very similar in purpose

Re: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Michael Stone: > Other platforms have deprecated gethostid, that's the best way forward > for linux, IMO. I agree. It's the most likely outcome if this issue was reported to glibc upstream.

Re: Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

* Richard Laager: > Getting back to ZFS and /etc/hostid... I would think that a > randomly-generated /etc/hostid is probably sufficient. Whether that's > done in the libc, spl, or zfs package makes no difference to me. As I tried to explain, the risks of collisions without central coordination lo

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

* Niels Thykier: > armel/armhf: > > > * Undesirable to keep the hardware running beyond 2020. armhf VM >support uncertain. (DSA) >- Source: [DSA Sprint report] Fedora is facing an issue running armhf under virtualization on arm64:

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

* Riku Voipio: > On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote: >> * Niels Thykier: >> >> > armel/armhf: >> > >> > >> > * Undesirable to keep the hardware running beyond 2020. armhf VM >> >s

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

* Florian Weimer: >> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >>in GCC >>(Raised by the GCC maintainer; carried over from stretch) > > I'm surprised to read this. ppc64el features prominently in the > toolchain work I do (th