Processed: severity of 679828 is wishlist
Processing commands for cont...@bugs.debian.org: > severity 679828 wishlist Bug #679828 [libc6] libc6: No easy way of enabling DNSSEC validation aka RES_USE_DNSSEC Severity set to 'wishlist' from 'serious' > thanks Stopping processing here. Please contact me if you need assistance. -- 679828: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679828 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.134121139132059.transcr...@bugs.debian.org
Bug#679828: libc6: No easy way of enabling DNSSEC validation aka RES_USE_DNSSEC
* Matthew Grant: > From my investigations this can only be enabled by recompiling each bit > of software to set the RES_USE_DNSSEC flag in _res.options, as well as > RES_USE_EDNS0. (Please see racoon bug #679483). The enablement method > is from openssh 6.0p1, openbsd-compat/getrrsetbyname.c This does not actually activate DNSSEC, it just tells the recursive resolver that the application is able to process DNSSEC records. The application would still have to validate them. Applications should never need to set the RES_USE_DNSSEC flag because it does not make sense to treat DNSSEC-signed data differently from unsigned data. > Please create a resolv.conf flag so that RES_USE_DNSSEC is available > to the systems administrator, and maybe a debconf screen to select it. This alone wouldn't make any difference to the spoofing problem. libc is not the correct place to put DNSSEC validation because many processes are shortlived and would have to fetch all key material and signatures from DNS, beginning at the root. This would turn a single name resolution into six or more DNS queries, which is excessive. At this stage, you should run a BIND or Unbound process restricted to localhost which performs the validation. This validation will happen even for applications which do not set the RES_USE_DNSSEC flag. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjdau1uj@mid.deneb.enyo.de
Bug#555168: Unclear license situation for (e)glibc locales provided by you
Raphael Finkel wrote: > Helge, > > I would be glad to relicense this work in whatever way will give it the > most distribution. I don't want to restrict it, but I would like my > name associated with it. Does that mean something like % This file has been put in the public domain. % You can do whatever you want with this file. % % 2003-08-16: corrections from Raphael Finkel % for locales/yi_US would be okay with you if Pablo Saratxaga is ok with it? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702052741.GA2986@burratino
Bug#555168: Unclear license situation for (e)glibc locales provided by you
Helge, I would be glad to relicense this work in whatever way will give it the most distribution. I don't want to restrict it, but I would like my name associated with it. Raphael > Hello, > you are listed as contact person/author of the following locale: > > yi_US > > This locale comes with a statement > > % Distribution and use is free, also > % for commercial purposes. > > Thus it does not allow modification; it is unclear, however, if this > statement was meant as a license. > > As discussed in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555168 this > locale could strictly speaking not be part of Debian which would be a > great loss. (Currently it is allowed pending investigation). > > To properly resolve this, I would like to ask you the following > question: > > Would you be willing to relicense this locale to a proper license, > e.g. (L)GPL v2 or higher or another free software license of your choice? > > If you have any questions regarding this issue, do not hesitate to > contact me (via the reply-to address set). > > Thanks for helping to resolve this! > > Helge > > -- > Dr. Helge Kreutzmann deb...@helgefjell.de >Dipl.-Phys. http://www.helgefjell.de/debian.php > 64bit GNU powered gpg signed mail preferred >Help keep free software libre: http://www.ffii.de/ -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702010115.ga32...@cs.uky.edu
Bug#671715: marked as done (libc6: Fail to upgrade from 2.13-27 to newer version !)
Your message dated Sun, 1 Jul 2012 14:01:34 +0200 with message-id <20120701120134.gb10...@ohm.aurel32.net> and subject line Re: Bug#671715: libc6: Fail to upgrade from 2.13-27 to newer version ! has caused the Debian Bug report #671715, regarding libc6: Fail to upgrade from 2.13-27 to newer version ! to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 671715: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671715 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.13-27 Severity: important Dear Maintainer, * What led up to the situation? My system (debian/testing) is using 2.13-27 version of libc6 and I'm trying to upgrade to the current testing version... * What exactly did you do (or not do) that was effective (or ineffective)? I'm trying to do an "aptitude install libc6" * What was the outcome of this action? It didn't finish well, I obtain the following messages : A copy of the C library was found in an unexpected directory: '/lib/x86_64-linux-gnu/libc-2.13.so' It is not safe to upgrade the C library in this situation; please remove that copy of the C library or get it out of '/lib/x86_64-linux-gnu' and try again. * What outcome did you expect instead? An upgrade without problem ! I have tryied : - to move that file -> nothing work after that so I cannot redo the upgrade ! - to use a rescue CD (PartedMagic), chroot the environement and try to force the upgrade, but I get the same result ! Is there any solution to make the upgrade happen without reinstalling the whole system ? Regards Mourad -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.3.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.13-32 ii libgcc1 1:4.7.0-3 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.42 ii glibc-doc ii locales2.13-32 -- debconf information: glibc/upgrade: true glibc/disable-screensaver: glibc/restart-failed: glibc/restart-services: libraries/restart-without-asking: false --- End Message --- --- Begin Message --- On Sat, Jun 30, 2012 at 10:00:02AM +0200, newbeewan wrote: > On 30/06/2012 01:27, Aurelien Jarno wrote: > >On Wed, May 23, 2012 at 07:07:05PM +0200, Aurelien Jarno wrote: > >>On Sun, May 06, 2012 at 11:14:56AM +0200, Mourad Jaber wrote: > >>>Package: libc6 > >>>Version: 2.13-27 > >>>Severity: important > >>> > >>>Dear Maintainer, > >>> > >>>* What led up to the situation? > >>>My system (debian/testing) is using 2.13-27 version of libc6 and I'm > >>>trying to > >>>upgrade to the current testing version... > >>> > >>>* What exactly did you do (or not do) that was effective (or > >>> ineffective)? > >>>I'm trying to do an "aptitude install libc6" > >>> > >>>* What was the outcome of this action? > >>>It didn't finish well, I obtain the following messages : > >>>A copy of the C library was found in an unexpected directory: > >>> '/lib/x86_64-linux-gnu/libc-2.13.so' > >>>It is not safe to upgrade the C library in this situation; > >>>please remove that copy of the C library or get it out of > >>>'/lib/x86_64-linux-gnu' and try again. > >>> > >>>* What outcome did you expect instead? > >>>An upgrade without problem ! > >>> > >>>I have tryied : > >>> - to move that file -> nothing work after that so I cannot redo the > >>> upgrade ! > >>> - to use a rescue CD (PartedMagic), chroot the environement and try to > >>> force > >>>the upgrade, but I get the same result ! > >>> > >>>Is there any solution to make the upgrade happen without reinstalling the > >>>whole > >>>system ? > >>> > >>This looks like your dpkg database is corrupted, or at least not in sync > >>with the files installed in your system. Can you please provide us the > >>contents of all the files named /var/lib/dpkg/info/libc6*.list ? > >> > >Ping ? > Sorry for the lack of response ! > > Unfortunately I have reinstalled the system using the CUT > installation CD (http://cut.debian.net/) and it works like a charm ! > > I received your first mail just after my reinstall and I haven't any copy of > the old /var :( > > I think you can close that bug. Ok, thanks for the answer, doing that with this mail. > I will reopen it if it happened again and in that case I will s
Bug#679828: libc6: No easy way of enabling DNSSEC validation aka RES_USE_DNSSEC
Package: libc6 Version: 2.13-34 Severity: Serious Tags: security Hi! I am submitting this report as there seems to be no easy way to get DNSSEC validation happening for all DNS lookups. This is a litmus test to make sure we cover this matter, or see if we have an easy procedure in wheezy to enable client DNSSEC validation. With the DNS root zone now signed, and .org and .net, and many soon to be done country specific TLDs, there does not appear to be any easy way of taking advantage of this in wheezy or sid. >From my investigations this can only be enabled by recompiling each bit of software to set the RES_USE_DNSSEC flag in _res.options, as well as RES_USE_EDNS0. (Please see racoon bug #679483). The enablement method is from openssh 6.0p1, openbsd-compat/getrrsetbyname.c Please create a resolv.conf flag so that RES_USE_DNSSEC is available to the systems administrator, and maybe a debconf screen to select it. This is about proactively avoiding DNS spoofing and securing against it. Regards, Matthew Grant -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.13-34 ii libgcc1 1:4.7.1-2 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.44 ii glibc-doc 2.13-34 ii locales2.13-34 -- debconf information: glibc/upgrade: true glibc/disable-screensaver: glibc/restart-failed: glibc/restart-services: libraries/restart-without-asking: false -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701215501.13452.25150.report...@shalom-ext.internal.anathoth.net
Bug#555168: Unclear license situation for (e)glibc locales provided by you
Hello, you are listed as contact person/author of the following locale: yi_US This locale comes with a statement % Distribution and use is free, also % for commercial purposes. Thus it does not allow modification; it is unclear, however, if this statement was meant as a license. As discussed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555168 this locale could strictly speaking not be part of Debian which would be a great loss. (Currently it is allowed pending investigation). To properly resolve this, I would like to ask you the following question: Would you be willing to relicense this locale to a proper license, e.g. (L)GPL v2 or higher or another free software license of your choice? If you have any questions regarding this issue, do not hesitate to contact me (via the reply-to address set). Thanks for helping to resolve this! Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ signature.asc Description: Digital signature
Bug#555168: Unclear license situation for (e)glibc locales provided by you
Hi, Zitat von Helge Kreutzmann : Would you be willing to relicense this locale to a proper license, e.g. (L)GPL v2 or higher or another free software license of your choice? Yes, it is fine with me. Mashrab. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701195958.95356clgs453g...@webmail.uni-bremen.de
