DFMR
Anyone wishing to be on the DFMR (Deb Freshmeat Repository) team should email [EMAIL PROTECTED] with the subject DFMR. I understand Freshmeat has _one_ person managing the RPM repository... -- Robert S. Edmonds Debian Developer (http://www.debian.org) mailto:[EMAIL PROTECTED] http://edmonds.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
freshmeat
freshmeat now has a deb repository. i have been busy all morning as a freshmeat staff member pulling down packages onto the freshmeat server and updating their appindex records. (scoop recently implemented the ability to provide a link to a deb directory on freshmeat) i updated 81 appindex records and their debs are stored on freshmeat's ftp server. (there are more than 81 .debs there, however, because some are split, e.g. gimp, amanda, vnc) if you maintain a package that is in freshmeat's appindex and your package is the latest version, and the link to the .deb is not on freshmeat, please email [EMAIL PROTECTED] and where the package is in debian as well as freshmeat. -- Robert S. Edmonds - Debian developerhttp://www.debian.org Freshmeat staff member http://freshmeat.net [EMAIL PROTECTED] / http://www.smart1.net/edmonds - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian volunteers needed for Atlanta Linux Showcase
Volunteers are needed for October's ALS. I already have several possible people that can man the booth. We need people around, or close to the Atlanta area to be able to help man the booth (bring your screamer box, etc.) and also less obvious donations. Redhat will be there with its ubiquitious free CDs. We need LSL or someone to donate a couple hundred CDs (attendance to ALS is expected to be 1000 or so), preferably a CD manufacturer who can press them cheaply. We also need literature, brochures, etc. we can pass out to people. As ALS will be held on October 23 and 24, we'll hope to be passing out *hamm* CDs... ;) -- Robert S. Edmonds - Debian developerhttp://www.debian.org Freshmeat staff member http://freshmeat.net [EMAIL PROTECTED] / http://www.smart1.net/edmonds - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Odd 4 (figure four) - appears almost like two colons
On Sat, Dec 09, 2000 at 08:13:08PM -0500, Branden Robinson wrote: > On Sat, Dec 09, 2000 at 07:02:53PM -0500, Joe Drew wrote: > > By any chance are you using XFree86 4.0? If so, this is a known bug I've > > seen on my Voodoo5, and Branden's seen on a G200 (I believe). > > Voodoo3. I don't have access to any Matrox hardware, unfortunately. But > yes, I see this problem all the time on the Voodoo3 cards I have around. i have seen obscure screen corruption (the entire screen) on the console when running XFree86 4.0.1 in 32 bpp color on a matrox G400. switching VTs and back fixes it, temporarily. switching to 24 bpp color fixes it permanently. -- Robert Edmonds [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Processing of ip4r_1.03-1_multi.changes]
On 2008-02-11, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Mon, Feb 11, 2008 at 05:13:21PM -0500, Robert Edmonds wrote: >> Luk Claes wrote: >> > It was rejected with the following message: > >> > Rejected: ip4r_1.03-1_multi.changes: Missing mandatory field `description'. > >> Hm, looks like mergechanges is to blame. > >> > You should have got a REJECTED mail telling you btw. > >> I never got a REJECTED mail. > > Right; if dak can't parse the .changes file, how should it know where to > send a mail? The Maintainer and Changed-By fields were perfectly parseable... -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED]: Processing of ip4r_1.03-1_multi.changes]
I uploaded these[0] files last week and expected to see a corresponding "ip4r_1.03-1_multi.changes is NEW" mail (due to the new binary package postgresql-8.3-ip4r), but one never came, nor do I see the package in NEW or incoming. Where did it go? I uploaded the package again last night but it similarly disappeared. [0] http://people.debian.org/~edmonds/ip4r/ - Forwarded message from Archive Administrator <[EMAIL PROTECTED]> - From: Archive Administrator <[EMAIL PROTECTED]> Subject: Processing of ip4r_1.03-1_multi.changes Date: Tue, 05 Feb 2008 00:01:43 + To: [EMAIL PROTECTED] ip4r_1.03-1_multi.changes uploaded successfully to localhost along with the files: postgresql-8.2-ip4r_1.03-1_i386.deb ip4r_1.03-1.dsc ip4r_1.03.orig.tar.gz postgresql-8.2-ip4r_1.03-1_amd64.deb postgresql-8.3-ip4r_1.03-1_i386.deb postgresql-8.3-ip4r_1.03-1_amd64.deb ip4r_1.03-1.diff.gz Greetings, Your Debian queue daemon - End forwarded message ----- -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [EMAIL PROTECTED]: Processing of ip4r_1.03-1_multi.changes]
Luk Claes wrote: > It was rejected with the following message: > > Rejected: ip4r_1.03-1_multi.changes: Missing mandatory field `description'. Hm, looks like mergechanges is to blame. > You should have got a REJECTED mail telling you btw. I never got a REJECTED mail. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#475493: ITP: python-pefile -- Portable Executable (PE) parsing module for Python
Package: wnpp Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]> Severity: wishlist * Package name: python-pefile Version : 1.2.9.1 Upstream Author : Ero Carrera <[EMAIL PROTECTED]> * URL : http://code.google.com/p/pefile/ * License : BSD Programming Lang: Python Description : Portable Executable (PE) parsing module for Python pefile is a Python module to read and work with Portable Executable (PE) files. Most of the information in the PE header is accessible, as well as all the sections, section information and data. . All the basic PE file structures are available with their default names as attributes of the returned instance. . Processed elements such as the import table are made available with lowercase names, to differentiate them from the upper case basic structure names. . pefile has been tested against the limits of valid PE headers; that is, Windows malware. Lots of packed malware attempt to abuse the format beyond its standard use. . Some of the tasks that pefile makes possible are: * Modifying and writing back to the PE image * Header inspection * Section analysis * Retrieving data * Warnings for suspicious and malformed values * Packer detection with PEiD signatures * PEiD signature generation -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: exim, local resolver, host name lookups and IPv6
'd like to > find a clean solution which could then be implemented in whatever part > of Debian might be responsible. > > I feel that the IPv6 issue is the same that led us to invoke the > 127.0.1.1 hack for IPv4, and if the answer to the IPv6 issue is "fix > exim", then _how_ should exim be fixed, and why wasn't the answer to > the IPv4 version of the issue "fix exim"? I don't see how this issue is analogous to the 127.0.1.1 hack. From reading the archived discussion[0], the problem is applications which use a sequence of legacy gethostname(), gethostbyname(), etc. calls to construct an FQDN, and avoiding accidentally using 'localhost' or 'localhost.localdomain' as the system hostname. If you're using the newer getipnode* functions, it's possible that you'll get an AI_V4MAPPED address even when asking for an AF_INET6 address. The analogous IPv6 hack, btw, would be something atrocious in /etc/hosts like: :::127.0.1.1 hostname.domainname > Any hints will be appreciated. IME, nullmailer and postfix seem to get along fine without generating spurious DNS traffic, so #include > Greetings > Marc > [0] http://lists.debian.org/debian-boot/2005/06/msg00938.html -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim, local resolver, host name lookups and IPv6
On 2008-04-11, Florian Weimer <[EMAIL PROTECTED]> wrote: > * Bernhard R. Link: > >> I think the main problem is that Debian is by default setting up those >> ipv6 stuff into the interface even when you are in an pure ipv4 >> environment. That way exim4 cannot do anything to avoid ipv6 stuff >> and evil things like this can happen. > > Yes, I agree this is a problem, because IPv6 still doesn't work out of > the box because IPv6 networking is initialized too late in the boot > process. How so? Do you mean a situation such as * no inet6 stanzas configured in /etc/network/interfaces * a daemon attempts to bind to an AF_INET6 socket late in the boot process * the kernel helpfully autoloads ipv6.ko * the kernel helpfully binds a "scope link" inet6 address to each network interface and performs router solicitation ? It's primarily the configuration of those "scope link" inet6 addresses which cause problems, right? Would loading ipv6.ko with net.ipv6.conf.all.autoconf = 0 help? -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim, local resolver, host name lookups and IPv6
Guus Sliepen wrote: > From the getipnodebyname(3) manpage: > > NOTES >These functions were present in glibc 2.1.91-95, but were removed >again. Several Unix-like systems support them, but all call them >deprecated. > > The best way is to use getaddrinfo() and getnameinfo(). Whoops; sorry. Those were the functions I was thinking of that supersede gethostby*(). -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim, local resolver, host name lookups and IPv6
On 2008-04-12, Marc Haber <[EMAIL PROTECTED]> wrote: > On Fri, 11 Apr 2008 17:48:19 +0000 (UTC), Robert Edmonds ><[EMAIL PROTECTED]> wrote: >>Yes, there is a much better way: do not perform name resolution to >>determine the host's FQDN. It is wrong. > > This is what exim does to determine the local host name: >|This variable contains the value set by primary_hostname in the >|configuration file, or read by the uname() function. If uname() returns a >|single-component name, Exim calls gethostbyname() (or getipnodebyname() >|where available) in an attempt to acquire a fully qualified host name. See >|also $smtp_active_hostname. > > Is this broken? IMO, yes: the nodename returned by uname() may have nothing to do with information in the DNS. I haven't looked at the exact sequence of calls exim makes, but a common one is: 1) obtain the hostname via uname() or gethostname() 2) obtain the IP address corresponding to this hostname by calling gethostbyname() 3) obtain the "fully qualified" hostname by calling gethostbyaddr() on this IP address This is somewhat damaged especially if the gethost* calls result in DNS lookups for some reason, because the information in DNS could be under a completely separate administrative domain. Another problem is insisting that a "single-component name" isn't fully qualified is wrong, too. E.g., "ai" is a fully-qualified Internet mail domain: [EMAIL PROTECTED]:~$ dig +short mx ai 10 mail.offshore.ai. > But this documentation is kind of incorrect in the first place, since > the lookup I see is caused by a call to gethostbyname_2_, which > is not mentioned int he docs at all. Thankfully, gethostbyname2 is > used in exim's source code only twice (with one of the occurrences > being inside an if( primary_hostname == NULL ) which doesn't apply if > primary_hostname is set in configuration, which is the case if exim is > configured with the minimaldns option. So, the lookup must be > triggered by the gethostbyname2 call in host.c line 1969, which I not > yet have fully understood. Can some more experienced C programmer > comment on this part of the code? > >> The MTA needs to know the >>"mail name" or FQDN of the system, and it may need to know specific IPv4 >>or IPv6 addresses to bind to if it is running an SMTP server, but it >>does not need to know any particular mapping between the two. > > Where can I obtain the FQDN of the system instead? Perhaps by asking the user at installation/configuration time, and storing this information in some sort of file that stores the, erm, "mail name" of the system :) > Don't I need the particular mapping between IP addresses and host > names to generate a proper HELO? But I wouldn't expect these lookups > to be made at startup, but only when an outgoing message is sent. No. >>It looks like there are functions in src/host.c for performing DNS-based >>determination of the system's FQDN. I don't know exactly under which >>circumstances these functions are invoked, but policy 11.6 implies that >>they are superfluous in the presence of the /etc/mailname file. > > /etc/mailname is unfortunately unclearly defined in Policy, and IIRC > the policy editors refused to clarify when asked years ago. The exim 4 > maintainers have then created http://wiki.debian.org/EtcMailName and > asked all MTA maintainers to comment how they use /etc/mailname, but > only a fraction of them bothered to comment. > > Exim 4 only uses /etc/mailname to qualify unqualified recipient > addresses and for some rewriting tricks. This has been the cause of > unspeakable grief in the past so I do prefer to avoid touching this > particular part of the system. > >>I don't see how this issue is analogous to the 127.0.1.1 hack. From >>reading the archived discussion[0], the problem is applications which >>use a sequence of legacy gethostname(), gethostbyname(), etc. calls to >>construct an FQDN, and avoiding accidentally using 'localhost' or >>'localhost.localdomain' as the system hostname. If you're using the >>newer getipnode* functions, it's possible that you'll get an AI_V4MAPPED >>address even when asking for an AF_INET6 address. > > It looks to me that the getipnode* functions are not available in > current Debian based on glibc 2.7. Yes, sorry. I meant the getaddrinfo() function. >>The analogous IPv6 hack, btw, would be something atrocious in /etc/hosts >>like: >> >>:::127.0.1.1 hostname.domainname > > I'll try that. Is there a bug report open where this is being discussed? >>>
Bug#482277: ITP: unbound -- validating, recursive, caching DNS resolver
Package: wnpp Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]> Severity: wishlist * Package name: unbound Version : 1.0.0 Upstream Author : NLnet Labs * URL : http://libev.schmorp.de/ * License : BSD Programming Lang: C Description : validating, recursive, caching DNS resolver Unbound is a validating, recursive, and caching DNS resolver. . The C implementation of Unbound is developed and maintained by NLnet Labs. It is based on ideas and algorithms taken from a java prototype developed by Verisign labs, Nominet, Kirei and ep.net. . Unbound is designed as a set of modular components, so that also DNSSEC (secure DNS) validation and stub-resolvers (that do not run as a server, but are linked into an application) are easily possible. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Time to phase out net-tools?
On 2008-06-13, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > On Fri, 13 Jun 2008, Martín Ferrari wrote: >> Both, I know that many people had written stuff on top of that output >> and interface. > > Including Debian. indeed, ifupdown being the most obvious impediment to making net-tools priority optional. >> > net-tools doesn't suffer any showstoppers, is there a good reason to >> > replace it at this time? iproute is indeed much better, but it is not even >> > part of a standard Debian install currently. Maybe that's something that >> > we should start with if we want to migrate towards iproute. >> >> It's not something to be done in a day. But I think that given the >> amount of bug net-tools has, and the fact that it can't do much of the >> cool stuff provided by 2.4+ kernels, it's time for its retirement. And >> yes, iproute should become priority important. agreed. > You could have that as a release goal for lenny+1: net-tools as an optional > package. This means changing everything in Debian that uses net-tools to > iproute (except for other optional packages), which could be a good thing by > itself. We do need some forced churning on part of our network > infrastructure, after all. > > But to rewrite net-tools as wrappers for iproute? I fail to see the point. > It is just wasted effort, IMHO. They already work, and they're not using > deprecated interfaces to the kernel AFAIK (if they are, things change). I > think it is better to direct our efforts to stop using net-tools as much as > we can, so as to make the package optional... that alone will take a lot of > effort by itself. indeed net-tools is using deprecated ioctls to the kernel vs. the netlink sockets that iproute uses. see for instance #222676, and the fact that aliases created with 'ip addr add ...' don't show up in ifconfig output. mii-tool seems to be mostly superseded by ethtool. nameif seems to be superseded by ifrename / udev. rarp is obsolete. iptunnel, ipmaddr, slattach, plipconfig? -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Time to phase out net-tools?
On 2008-06-17, Luk Claes <[EMAIL PROTECTED]> wrote: > Robert Edmonds wrote: >> rarp is obsolete. > It's not, I do use it from time to time, do you have a replacement? sorry, I mean rarp(1) is obsolete, according to its manpage: NOTE This program is obsolete. From version 2.3, the Linux kernel no longer contains RARP support. sure, you can run a userspace rarp daemon all you want. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#535396: ITP: wrapsrv -- DNS SRV record command line wrapper
Package: wnpp Owner: "Robert S. Edmonds" Severity: wishlist * Package name: wrapsrv Version : 0.1 Upstream Author : Internet Systems Consortium, Inc. * URL : ftp://ftp.isc.org/isc/toolmakers/wrapsrv/ * License : ISC Programming Lang: C Description : DNS SRV record command line wrapper wrapsrv adds support for connecting to a network service based on DNS SRV record lookups to commands that do not support the DNS SRV record. wrapsrv implements the weighted priority client connection algorithm in RFC 2782. The specified command line will be invoked one or more times with %h and %p sequences in the command line substituted for the hostname and port elements of the selected SRV record. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
ITP: lckdo -- execute a program with a lock set
Package: wnpp Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]> Severity: wishlist * Package name: lckdo Version : 0 Upstream Author : Michael Tokarev <[EMAIL PROTECTED]> * URL : http://www.corpit.ru/mjt/lckdo.c * License : public domain Programming Lang: C Description : execute a program with a lock set lckdo is a utility for controlling the invocation of another program based on a lock file. It supports both shared (read) and exclusive (write) locks and can wait for a configurable amount of time for the lock to become free. lckdo is commonly used to make automated rsync mirroring more robust. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#320283: ITO: re2c
The spamassassin just uploaded to unstable has a new feature for compiling rulesets to native code which apparently results in a large performance boost[0]. The sa-compile(1p) man page states that re2c version 0.10.x is required for this functionality, and only an orphaned 0.9.x is available in Debian. I intend to adopt re2c and upload the latest upstream version (0.12.1). [0] http://lwn.net/Articles/232696/ -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#320283: ITA: re2c
[ The subject should have read "ITA", not "ITO". ] Duncan Findlay wrote: > Whoops, looks like I missed that dependency on re2c >= 0.10.0 for > spamassassin, but I think it's working fine with 0.9.x. (At least, I > haven't found a problem with it.) That's fortunate; I guess spamassassin upstream developed their support against re2c 0.10, which I believe was the previous stable release before 0.12. According to the upstream re2c changelog, there's been a lot of activity since 0.9.12. > I'd be happy to co-maintain the package if you would like a > co-maintainer. (Though I'm not going to have much time for Debian in > the next couple of weeks.) Thanks, but I think I can handle a single binary package like re2c just fine. As a devoted spamassassin user, spamassassin compatibility is my top priority for re2c. BTW, are you planning to fix the sa-update cron spam issue (#425962) soon? :) -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#431809: ITP: podofo -- library and tools to work with the PDF file format
Package: wnpp Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]> Severity: wishlist * Package name: podofo Version : 0.5.0 Upstream Author : Dominik Seichter * URL : http://podofo.sourceforge.net/ * License : GPLv2 or later, LGPLv2 or later Programming Lang: C++ Description : library and tools to work with the PDF file format PoDoFo is a library and set of tools to work with the PDF file format. The name comes from the first letters of PDF (Portable Document Format). . The PoDoFo library is a free, portable C++ library which includes classes to parse PDF files and modify their contents. PoDoFo can also create PDF files. . The following tools are included: . * podofoimgextract extracts all jpeg images from a given PDF file . * podofouncompress removes all compression filters from a PDF file; this is useful for debugging existing PDF files . * podofopdfinfo provides some basic info about a PDF - metadata, page details, etc. . * podofotxt2pdf converts a text file to a PDF I also intend to package the podofobrowser program. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#500176: This bug is still around and release-critical
On 2008-10-05, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > FWIW this problem is found in many other cases: see lighttpd with > apache2 installed, or caudium or any other http daemon, and none of them > has a bug about it, it's unfair to mark it as RC. also note that this bug isn't symmetric with bind9, which opportunistically attempts to bind every ip address on the system. (in fact, it will periodically re-scan the interfaces list and attempt to bind new ip address on the system; see the 'interface-interval' setting.) if no addresses can be bound, named will still start. i just installed bind9 on a test system running unbound and found that the bind9 package installed rc?.d symlinks at the S15 level, which causes it to start sooner than unbound at S85. after a reboot, unbound will fail to start since bind9 has bound the ip addresses unbound uses. (by default, unbound only tries to bind 127.0.0.1 and ::1). so installation in the order (unbound, bind9) will succeed and both daemons will start, but at boot the startup order (bind9, unbound) will fail. > I believe the problem here is somehow very generic, and that using a > virtual package like proposed in the bug report (#500176) doesn't scale > well. Especially for dns daemons. Packaging two of them myself (nsd3 > that is an authoritative server only, and pdnsd that is a caching daemon > only) I can tell the virtual package solution would be a mess: I _want_ > to be able to use nsd3 _and_ pdnsd on the same machine (I actually do > since the former binds to the external IPs only and pdnsd to 127.0.0.1) > but by default nsd3 listens on 0.0.0.0 and you can't apt-get install > pdnsd if you haven't configured nsd3 properly first. And you cannot make > both conflict, both should work fine. yes, virtual packages are a nonstarter because of all the strange ways dns can be combined on the same machine (see, e.g., the dnsproxy package). -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503395: ITP: libapache2-mod-spamhaus -- Apache module that use DNSBL to deny access to a known bad IP address
On 2008-10-25, Giuseppe Iuculano <[EMAIL PROTECTED]> wrote: > It take advantage of the Spamhaus Block List (SBL) and the Exploits > Block List (XBL) querying xbl-sbl.spamhaus.org Spamhaus's DNSBLs are > offered as a free public service for low-volume non-commercial use. the combined SBL/XBL zone is sbl-xbl.spamhaus.org. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503395: ITP: libapache2-mod-spamhaus -- Apache module that use DNSBL to deny access to a known bad IP address
On 2008-10-25, Ralf Hildebrandt <[EMAIL PROTECTED]> wrote: > Or zen.spamhaus.org (which is actually a BIT more, but the recommended > list) zen includes PBL, which certainly shouldn't be used for denying access to http service. i'm unsure why this program is named mod_spamhaus; it appears to be a DNSBL access control filter for apache that can only query one DNSBL zone. i also notice that mod_spamhaus's DNSBL lookup routine only checks for the presence or absence of a host record, rather than checking like a sensible DNSBL client that the response lies in the 127/8 range. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
deb-ice -- violating the GPL since 2007-08-14
"deb-ice" is a custom Debian distribution, described in [0] and available from [1]. It appears to be a preseeded Debian 4.0 i386 business card ISO built using a web-based tool called LinuxCOE[2], and the aggregator has attempted to place the entire work under a license[3] which appears to be the GPLv2 with the string "GNU GENERAL PUBLIC LICENSE" stripped out. This is troubling for several reasons: 0) Changing the GPL is not allowed. 1) No source code is included. 2) The following files distributed in the ISO are certainly not licensed under the (simultaneously claimed and violated!) GPL: ./pool/main/o/openssh/openssh-client-udeb_4.3p2-9_i386.udeb ./pool/main/o/openssh/openssh-server-udeb_4.3p2-9_i386.udeb ./pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8c-4_i386.udeb The aggregator needs to either immediately stop distributing this ISO or provide source code for the components that require source code and clarify that the entire work is not under a single GPL license. [0] http://icelinux.net/ [1] http://sourceforge.net/project/showfiles.php?group_id=203391 [2] http://linuxcoe.sourceforge.net/ [3] http://downloads.sourceforge.net/deb-ice/DebIce_LICENSE.txt -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
Package: wnpp Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]> Severity: wishlist * Package name: tg3dfsg Version : 3.81 Upstream Author : Various * URL : http://people.debian.org/~edmonds/tg3dfsg/ * License : GPLv2 Programming Lang: C Description : firmware free Broadcom Tigon3 network driver This package provides the source code for the tg3dfsg kernel module. Kernel source or headers are required to compile this module. This driver complies with GR 2006-004 and should support all Tigon3 hardware except for 5701a0 chipsets. I intend to upload it should linux kernel images be uploaded which lack the tg3 driver. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
Faidon Liambotis wrote: > Robert Edmonds wrote: >> This package provides the source code for the tg3dfsg kernel >> module. Kernel source or headers are required to compile this module. >> >> This driver complies with GR 2006-004 and should support all Tigon3 >> hardware except for 5701a0 chipsets. I intend to upload it should >> linux kernel images be uploaded which lack the tg3 driver. > This doesn't sound good. > > Any reason why your 5701a0-removal patch can't be applied to our kernel > packages? > > Or even better, why the driver can't be converted to use > request_firmware() instead of embedding the firmware to the source? There are three hunks of firmware code in the tg3 driver; the other two enable TSO on chipsets which lack TSO firmware in silicon, but AFAIK these chips should function without TSO. (In fact, TSO has been disabled in this driver in the past.) Any modification to the tg3 driver to produce a GR 2006-004 compliant driver would have to diverge from the kernel team's patch acceptance guidelines[0] since upstream is intransigent[1] on making tg3 firmware-free or firmware-optional. The kernel team does not appear to be interested in maintaining such a driver, and it appears future linux kernel source packages will be patched[2] to simply remove the blobs of firmware (I don't know why the driver isn't simply removed entirely since the result does not compile). Obviously, since I and many other users have computers with embedded Tigon3 hardware, I would be delighted if this package were unnecessary. [0] http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines [1] http://article.gmane.org/gmane.linux.debian.devel.kernel/32543/ [2] http://tinyurl.com/36xr2b, http://tinyurl.com/2u2cu5 -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
Faidon Liambotis wrote: > Robert Edmonds wrote: > > Any modification to the tg3 driver to produce a GR 2006-004 compliant > > driver would have to diverge from the kernel team's patch acceptance > > guidelines[0] since upstream is intransigent[1] on making tg3 > > firmware-free or firmware-optional. The kernel team does not appear to > > be interested in maintaining such a driver, and it appears future linux > > kernel source packages will be patched[2] to simply remove the blobs of > > firmware (I don't know why the driver isn't simply removed entirely > > since the result does not compile). > This seems totally inappropriate. > > If the driver includes non-free firmwares these should be removed or > split up from the driver source, not remove the driver entirely. > If what you say is right, the driver *works* for most of the hardware > without non-free blobs. > Therefore, I can't understand how removing the driver serves our users. That is why I said "appear", since I hope that the kernel team has plans for the driver beyond simply eliding it. (I'd like to point out that the equivalent FreeBSD if_bge driver has no firmware blobs.) > Any rationale behind that decision? > I feel like I'm arguing for something completely obvious... The only rationale for removing the *firmware* is compliance with GR 2006-004... -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
On 2007-10-10, Daniel Schepler <[EMAIL PROTECTED]> wrote: > On Wednesday 10 October 2007 02:57:59 pm Robert Edmonds wrote: >> The only rationale for removing the *firmware* is compliance with GR >> 2006-004... > > Reading this feels about like reading someone write, "The only rationale for > not smoking cigarettes in this restaurant is compliance with state law." > > How about not suggesting that the majority of Debian developers who voted for > that GR were crazy people making a decision with no rational basis? You > might disagree with it, but at least try to understand that there was a > reason for it that seemed valid to a lot of people. s/voted for/voted on/ -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448810: ITP: fcapture -- network flow capture utility
Package: wnpp Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]> Severity: wishlist * Package name: fcapture Version : 0.0.1 Upstream Author : me * URL : http://people.debian.org/~edmonds/fcapture/ * License : MIT/X11 Programming Lang: C Description : network flow capture utility fcapture is a utility to capture and dump IPv4 TCP/UDP flow information from a network interface or pcap save file. The accompanying fcapdump utility converts these flow capture dump files into human readable output. . fcapture can monitor high speed links and is more frugal in terms of disk space and CPU usage than similar programs like argus which use more detailed flow log formats. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#448810: ITP: fcapture -- network flow capture utility
On 2007-11-01, Robert Edmonds <[EMAIL PROTECTED]> wrote: > * URL : http://people.debian.org/~edmonds/fcapture/ If anyone wants to review this program/package before it hits incoming (especially if you're interested in network security monitoring), I've just uploaded source and binary packages from svn trunk here. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449322: ITP: pcaputils -- specialized libpcap utilities
Package: wnpp
Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]>
Severity: wishlist
* Package name: pcaputils
Version : 0.0.1
Upstream Author : me
* URL : http://people.debian.org/~edmonds/pcaputils/
* License : MIT/X11
Programming Lang: C
Description : specialized libpcap utilities
pcaputils includes the following libpcap-based utilities:
- pcapip: filters an input pcap file based on a file containing IP addresses
- pcappick: picks specific frames out of a pcap by number
- pcapuc: prints unique src IPs, dst IPs, or {src, dst} IP pairs witnessed
Also included is pcapdump, a dedicated packet capture utility similar to
dumpcap, but with these features:
- logs packet dump and drop rates
- can run as a daemon
- can dynamically reload its configuration without dropping packets
- can be signalled to immediately rotate its capture output file
- can partition its output based on time intervals (e.g., start of hour or
start of day)
--
Robert Edmonds
[EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: ries.debian.org AKA ftp-master.debian.org back
On 2007-11-12, Adeodato Simó <[EMAIL PROTECTED]> wrote: > ftp-master now runs Apache 2 instead of 1, and the directory listing > formatting has changed in that version (a instead of ). > You'll have to live with that (but, alas, it'll not only be incoming.d.o > where you'll be experiencing/suffering it, as more hosts move to apache2). Not if NameWidth=* is in your IndexOptions. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#450909: ITP: vblade-persist -- create/manage supervised AoE exports
On 2007-11-12, Daniel Kahn Gillmor <[EMAIL PROTECTED]> wrote: > As i'm not a DD, I'll need a sponsor to upload this package. Hi, I'll sponsor your package. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LSB-ize daemon without pidfile handling
On 2007-11-14, Marc Haber <[EMAIL PROTECTED]> wrote:
> On Sun, 11 Nov 2007 11:47:49 +, Stephen Gran <[EMAIL PROTECTED]>
> wrote:
>>This one time, at band camp, Marc Haber said:
>>> How many seconds until the "please make pidfile location configurable"
>>> wishlist bug?
>>
>>Which is another, what, 5-10 lines of code?
>
> I do not feel able to write C code for string operations without
> introducing a truckload of buffer overflows and off-by-one-errors.
Have you tried asking the author of ser2net if he is willing to add the
functionality...?
Anyway, here's a (compile-tested only) patch:
--- ser2net-2.3/ser2net.c 2005-03-10 10:59:53.0 -0500
+++ ser2net-2.3.pidfile/ser2net.c 2007-11-14 12:56:07.885930455 -0500
@@ -41,6 +41,7 @@
static char *config_file = "/etc/ser2net.conf";
static char *config_port = NULL;
+static char *pid_file = NULL;
static int detach = 1;
static int debug = 0;
#ifdef USE_UUCP_LOCKING
@@ -59,6 +60,7 @@ static char *help_string =
" you must specify a -c after the last -C to have it read a config\n"
" file, too."
" -p - Start a controller session on the given TCP port\n"
+" -P - set location of pid file\n"
" -n - Don't detach from the controlling terminal\n"
" -d - Don't detach and send debug I/O to standard output\n"
#ifdef USE_UUCP_LOCKING
@@ -83,6 +85,16 @@ arg_error(char *name)
exit(1);
}
+void
+make_pidfile(char *pidfile)
+{
+FILE *fpidfile;
+if (pidfile && (fpidfile = fopen(pidfile, "w"))) {
+ fprintf(fpidfile, "%d\n", getpid());
+ fclose(fpidfile);
+}
+}
+
int
main(int argc, char *argv[])
{
@@ -147,6 +159,15 @@ main(int argc, char *argv[])
}
config_port = argv[i];
break;
+
+ case 'P':
+ i++;
+ if (i == argc) {
+ fprintf(stderr, "No pid file specified with -P\n");
+ arg_error(argv[0]);
+ }
+ pid_file = argv[i];
+ break;
#ifdef USE_UUCP_LOCKING
case 'u':
@@ -206,6 +227,10 @@ main(int argc, char *argv[])
close(0);
close(1);
close(2);
+
+ /* write pid file */
+ make_pidfile(pid_file);
+
} else if (debug) {
openlog("ser2net", LOG_PID | LOG_CONS | LOG_PERROR, LOG_DAEMON);
}
--
Robert Edmonds
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein
Package: wnpp Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]> Severity: wishlist * Package name: djbdns Version : 1.05 Upstream Author : Daniel J. Bernstein * URL : http://cr.yp.to/djbdns.html * License : public domain Programming Lang: C Description : Replacement for BIND, written by Dan Bernstein The following were taken from various HTML pages under http://cr.yp.to/djbdns.html . dnscache is a local DNS cache. It accepts recursive DNS queries from local clients such as web browsers and mail transfer agents. It collects responses from remote DNS servers. It caches the responses to save time later. . tinydns is a DNS server. It accepts iterative DNS queries from hosts around the Internet, and responds with locally configured information. . pickdns is a load-balancing DNS server. It accepts iterative DNS queries from hosts around the Internet, and responds with a dynamic selection of locally configured IP addresses with 5-second TTLs. . walldns is a reverse DNS wall. It accepts iterative DNS queries for in-addr.arpa domains from hosts around the Internet, and supplies generic responses that avoid revealing local host information. . rbldns is an IP-address-listing DNS server. It accepts iterative DNS queries from hosts around the Internet asking about various IP addresses. It provides responses showing whether the addresses are on a locally configured list, such as RBL or DUL. . axfrdns is a DNS zone-transfer server. It reads a zone-transfer request in DNS-over-TCP format from its standard input, and responds with locally configured information. . The security of this software is guaranteed by the author. Details of the guarantee can be found at http://cr.yp.to/djbdns/guarantee.html (snagged from the djbdns-installer djbdns description) Supposedly DJB has released all of his code into the public domain. If this is really the case and passes DFSG, I plan to package djbdns assuming Adam McKenna (maintainer of djbdns-installer) doesn't want to. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#457778: ITP: blm -- compute set operations on line-oriented files: and, or, xor, and more.
On 2007-12-25, Rudi Cilibrasi <[EMAIL PROTECTED]> wrote: > * Package name: blm > Description : compute set operations on line-oriented files: and, or, > xor, and more. What are the time and space complexities for the various operations? -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459268: ITP: libev -- high-performance event loop library modelled after libevent
Package: wnpp Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]> Severity: wishlist * Package name: libev Version : 2.01 Upstream Author : Marc Alexander Lehmann * URL : http://libev.schmorp.de/ * License : BSD Programming Lang: C Description : high-performance event loop library modelled after libevent libev provides a full-featured and high-performance event loop that is loosely modelled after libevent. It includes relative timers, absolute timers with customized rescheduling, synchronous signals, process status change events, event watchers dealing with the event loop itself, file watchers, and even limited support for fork events. It uses a priority queue to manage timers and uses arrays as fundamental data structure. It has no artificial limitations on the number of watchers waiting for the same event. . libev supports select, poll, epoll, kqueue, and inotify. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#459401: ITP: c-repl -- read-eval-print loop for C
Package: wnpp Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]> Severity: wishlist * Package name: c-repl Version : 0.0.20071223 Upstream Author : Evan Martin * URL : http://neugierig.org/software/c-repl/ * License : BSD Programming Lang: C, Ruby Description : read-eval-print loop for C Many programming languages come with a REPL (read-eval-print loop), which allows you to type in code line by line and see what it does. This is quite useful for prototyping, experimentation, and debugging code. . Other programming languages, and especially C, use a "compile-run" model, and don't provide a REPL. Let's fix that. . This approach is actually more of a read-eval loop, as c-repl doesn't know anything about the types and parse trees of the code it's running. But unlike other approaches to solving the "C interpreter" problem, c-repl works directly with unmodified libraries and system headers. . This means you can experiment with a new library without writing a test program or any bindings. Or just use it as a simple calculator, content in knowing it is much faster than your neighbors using irb, like driving a Ferarri on city streets. -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
for those who care about unbound (resolvconf and DNSSEC)
hi, i'd like to get some feedback on whether i should implement some changes in the unbound debian packaging: * integration with resolvconf as a provider of recursive DNS resolution. (#562031) * retrieving a list of upstream recursive DNS servers from resolvconf and automatically configuring these servers as forwarders, and deconfiguring them when they are no longer available. (#567879) * enabling DNSSEC validation by default. (#594911) i'm inclined to implement all three of these features and make them each individually toggle-able via /etc/default/unbound, and to enable these features by default, but i would like to hear some wider opinions. (i have never even used resolvconf before.) there are some sub-issues such as: * automatically creating key material and configuration for unbound-control (a la bind9 and rndc) so that unbound-control can be used to reload the forwarder configuration without dumping the cache. * making sure we don't accidentally attempt to configure ourselves as a forwarder. * how, or whether to include the root trust anchor. unbound now has a utility called unbound-anchor which attempts to fetch an updated root trust anchor from https://data.iana.org/root-anchors/, using a built-in copy of the ICANN HTTPS cert (so, it doesn't rely on x509 PKI); failing that, it writes out a built-in copy of the root trust anchor. it would be possible to invoke unbound-anchor in the unbound postinst in order to write out a trust anchor file into e.g. /var/cache/unbound, which is then referenced by the unbound config file, and it would also be possible to re-invoke unbound-anchor in the unbound init script. this would mean that a DNS server with the unbound package would cause HTTPS connections to be made, although if these connections failed there would be a fall-back trust anchor used. it's possible that at some point in the future old versions of unbound-anchor would no longer be able to securely generate an up-to-date root trust anchor file, but i believe this could be adequately handled by a stable-security or stable point release update. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Re: for those who care about unbound (resolvconf and DNSSEC)
On 2011-02-17, Daniel Baumann wrote: > On 02/17/2011 05:07 AM, Robert Edmonds wrote: >> i'm inclined to implement all three of these features and make them each >> individually toggle-able via /etc/default/unbound, and to enable these >> features by default > > in order to do that for the first two that involve resolvconf, does that > mean you're going to add a depends on resolvconf (rather than e.g. a > recommends)? i'd prefere to not have resolvconf pulled in hard. let me rephrase: the resolvconf options would be enabled by default, but would be no-ops unless resolvconf is installed. and i think the package would only Suggest: resolvconf. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ijina1$b0k$1...@dough.gmane.org
Re: for those who care about unbound (resolvconf and DNSSEC)
Robert Edmonds wrote: > i'd like to get some feedback on whether i should implement some changes > in the unbound debian packaging: i'm also looking into building the python bindings for libunbound. unfortunately upstream uses autotools / libtool to build and link the python module, which results in the python extension module being linked against every library the configure script can find. short of rewriting the upstream build system i could only come up with the following to make the build link against only the required libraries: # XXX gross hack to prevent python module from linking against everything rm -f _unbound.la sed -i -e 's/^dependency_libs=.*/dependency_libs=''/' libunbound.la make _unbound.la LIBS="" install -m 0644 .libs/_unbound.so.2.*.* \ debian/python-unbound/usr/lib/pyshared/python2.6/_unbound.so but that's really gross. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#527985: ITP: libbind -- DNS resolver and message parsing library
Package: wnpp Owner: "Robert S. Edmonds" Severity: wishlist * Package name: libbind Version : 6.0 Upstream Author : Internet Systems Consortium, Inc. * URL : https://www.isc.org/software/libbind * License : ISC Programming Lang: C Description : DNS resolver and message parsing library libbind contains the standard resolver library that was distributed in BIND9 prior to version 9.6. Included are functions that communicate with domain name servers, parse DNS messages, retrieve network host entries from /etc/hosts or via DNS, convert CIDR network addresses, perform Hesiod information lookups, retrieve network entries from /etc/networks, implement TSIG transaction/request security of DNS messages, perform name-to-address and address-to-name translations, and use /etc/resolv.conf for resolver configuration. . note that the bind9 source package already ships a "libbind-dev" package which is unrelated to libbind. i will probably embed the SONAME version in the -dev package name for libbind to avoid conflicting with the bind9 package. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#528147: ITP: protobuf-c -- protocol buffers C compiler
Package: wnpp Owner: "Robert S. Edmonds" Severity: wishlist * Package name: protobuf-c Version : 0.10 Upstream Author : Dave Benson * URL : http://protobuf-c.googlecode.com/ * License : Apache 2.0 Programming Lang: C, C++ Description : protocol buffers C compiler Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format. . This is the C implementation of protocol buffers. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Re: Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
Ondřej Surý wrote: > Package: wnpp > Severity: wishlist > Owner: "Ondřej Surý" > > * Package name: dnssec-root-key Hm, I would maybe call this dnssec-root-anchors. Technically there should be very few copies of the root key :-) Similarly, s/key/trust anchors/g in the descriptions? > Version : 20100715 > Upstream Author : ICANN/IANA > * URL : http://data.iana.org/root-anchors/ > * License : Public Data (same as with root.zone) It might be nice to include a copy of this document in /usr/share/doc: http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.txt Since it looks like this is the only place where a schema is defined for the root-anchors.xml file. But I guess we would need a better (non-)license than this: Copyright (c) 2010 Internet Corporation For Assigned Names and Numbers. > Programming Lang: None > Description : This package contains DNSSEC root key > > This package contains DNSSEC root key in all available > formats that all packages doing DNSSEC validation can > use as a common data source. > . > unbound-anchor is used to keep the root.key up-to-date > via RFC5011 mechanism. > > -- > > PERSONAL NOTE: I now maintain at least two packages that > need DNSSEC root.key (hash-slinger and getdns[1]). There > are at least bind9, unbound and dnsmasq that can use this > as well. > > > 1. Waiting for next upstream release with proper libtool > flags. So, I wonder if this package should be responsible for providing the root-anchors.xml file, and the bind9/unbound/dnsmasq/etc. packages should be responsible for converting that from XML to whatever format they use (and unfortunately it appears every different program uses a different trust anchor format). Or by "all available formats" do you mean that this source package should take the root-anchors.xml file and generate several common formats (at package build time?) and provide them in /usr/share alongside the original root-anchors files from iana.org, so that DNSSEC software packages don't need an XML dependency? (Though, bind9 and unbound-anchor already pull in XML parsing libraries, but e.g. dnsmasq currently does not.) Should we patch unbound-anchor so that its fallback mode (where it tries to fetch files from https://data.iana.org/root-anchors/) can be made to check file:///usr/share/dnssec-root-anchors/ first? (And if so, it'd be nice to upstream that.) Should we do anything about the built-in static content in unbound-anchor that would be duplicative of the content in this package? I'm talking about this: http://anonscm.debian.org/gitweb/?p=users/edmonds/unbound.git;a=blob;f=smallapp/unbound-anchor.c;h=8ea4726b06313bf2f910d07f870d4e5350e25bce;hb=HEAD#l207 And this: http://anonscm.debian.org/gitweb/?p=users/edmonds/unbound.git;a=blob;f=smallapp/unbound-anchor.c;h=8ea4726b06313bf2f910d07f870d4e5350e25bce;hb=HEAD#l237 And, finally, is it known that the root DNSSEC key will be rolled over with RFC 5011 semantics? Anyway, consider this email an offer to co-maintain :-) -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626223252.ga2...@mycre.ws
Re: Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
Ondřej Surý wrote:
> Hi Robert,
>
> On Fri, Jun 27, 2014, at 00:32, Robert Edmonds wrote:
> > Ondřej Surý wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: "Ondřej Surý"
> > >
> > > * Package name: dnssec-root-key
> >
> > Hm, I would maybe call this dnssec-root-anchors. Technically there
> > should be very few copies of the root key :-)
>
> I ended up with dns-root-data, and also included root.zone and
> root.hints.
Hi, Ondřej:
I'm opposed to including the root zone in the same package as the
package containing the root trust anchors. Actually, I don't think the
root zone belongs in a Debian package at all.
Of course, the root zone changes very frequently, once a day or so, and
the signatures have a relatively short duration -- looking at a copy of
the zone, I see the signatures expire next week. So if the root zone
were in a Debian package, we would either have to update it extremely
frequently (qualifying it for volatile) to keep it validatable, or
update it infrequently enough that it would nearly always have expired
signatures. But with new TLDs being added to the root zone frequently,
it would still have to be updated fairly regularly (e.g., look at how
frequently the tzdata package is updated; or maybe a better example is
the publicsuffix package). Ideally the package containing the root
trust anchor would be updated so infrequently and the contents would be
so stable that many people would be able to scrutinize every single line
of changes between two versions of the package; if the root zone is in
the same package then the diff becomes much larger and makes it easier
to miss critical changes.
Can you identify a concrete use case for having the complete root zone
in a Debian package? Is there maybe something that wants an up-to-date
list of TLDs, or something like that? It seems to be a much different
use case from DNSSEC validation.
If we do need a way to get the root zone installed into a standard
location on Debian systems, I think it would be better to have a
separate "downloader" package. We can do this securely once we can
depend on a package containing the root trust anchor :-)
Something like a "dns-root-zone" package: it would depend on the package
containing the root trust anchor, but it would not contain a copy of the
root zone, instead shipping a script like "update-root-zone" that would
try to fetch the root zone from a few well-known authoritative locations
like:
http://ftp.internic.net/domain/root.zone.gz (ICANN)
ftp://rs.internic.net/domain/root.zone.gz (Verisign)
Then uncompress and dnssec-verify it in a temporary location before
installing it into /usr/share. Sort of like what you currently have in
dns-root-data's debian/rules, but it would be something that could be
run by the administrator periodically or on demand, kind of like
"update-pciids", rather than only by the package maintainers.
As for the root hints, I think that it might be a good idea to include
that in a Debian package. The bind9 and unbound daemons could be made
to directly consume that file as-is instead of relying on their built-in
root hints. (Though, unless we were to patch out the built-in hint
content entirely from those packages, which I don't think is a good
idea, we would still have to stable update a bunch of packages when a
root nameserver address changes.)
I think the package split should be between e.g. "dns-root-anchors"
(root anchor related content only) and "dns-root-zone" (containing root
zone hints and a downloader for the full root zone).
> The git repo resides at github.com at the moment as I feel it's not
> appropriate for collab-maint:
>
> https://github.com/oerdnj/dns-root-data
>
> > Similarly, s/key/trust anchors/g in the descriptions?
>
> Yep, already fixed that:
>
> Package: dns-root-data
> Architecture: all
> Depends: ${misc:Depends}
> Description: DNS root data including root zone and DNSSEC key
> This package contains various root zone related data as published
> by IANA to be used by various DNS software as a common source
> of DNS root zone data, namely:
> .
> * Root Hints and Zone Files (root.hints, root.zone)
> * Root Trust Anchors (root.key, root.ds)
>
> > > Version : 20100715
> > > Upstream Author : ICANN/IANA
> > > * URL : http://data.iana.org/root-anchors/
> >
> > > * License : Public Data (same as with root.zone)
> >
> > It might be nice to include a copy of this document in /usr/share/doc:
>
> True, fixed in git.
>
> > http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.txt
> >
> > Since it looks like this is the only place
Bug#765629: RFA: adns -- Asynchronous-capable DNS client library and utilities
Package: wnpp Severity: normal Hi, I request an adopter for the adns package. The package description is: adns is a resolver library for C (and C++) programs. In contrast with the existing interfaces, gethostbyname et al and libresolv, it can be used in an asynchronous, non-blocking manner. Many queries can be handled simultaneously. . Includes useful test tools and utilities for IP address resolving in logfiles. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016182207.ga8...@mycre.ws
Bug#724452: ITP: ifupdown-multi -- multiple default gateway support for ifupdown
Package: wnpp Severity: wishlist Owner: Robert S. Edmonds * Package name: ifupdown-multi Version : 0.1.0 Upstream Author : Farsight Security, Inc. * URL : https://github.com/farsightsec/ifupdown-multi * License : Apache-2.0 Programming Lang: Python Description : multiple default gateway support for ifupdown This package integrates support for multiple default gateways on independent network connections into the Debian ifupdown network interface configuration system. It adds new "multi_*" options to the /etc/network/interface file format in order to more easily configure Linux's policy based routing. . The policy information used to configure each network interface using ifupdown-multi is saved when ifup is run. This allows network interfaces using ifupdown-multi to be brought up or down cleanly as needed. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#647063: ITP: nss-ubdns -- NSS module for DNSSEC validated hostname lookups
Package: wnpp Severity: wishlist Owner: Robert S. Edmonds * Package name: nss-ubdns Version : 0.1 Upstream Author : Robert Edmonds * URL : https://github.com/edmonds/nss-ubdns * License : ISC, BSD, LGPL-2.1 Programming Lang: C Description : NSS module for DNSSEC validated hostname lookups The nss-ubdns module for the glibc NSS (Name Service Switch) interface returns DNSSEC validated lookups to the NSS "hosts" database. It is a replacement for the standard libresolv based "dns" module that uses the libunbound library for caching and validation. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#661208: ITP: mtbl -- immutable sorted string table library
Package: wnpp Severity: wishlist Owner: Robert S. Edmonds * Package name: mtbl Version : 0.1 Upstream Author : Internet Systems Consortium, Inc. * URL : https://github.com/edmonds/mtbl * License : ISC, BSD-3-Clause, Apache-2.0 Programming Lang: C Description : immutable sorted string table library mtbl is a C library implementation of the Sorted String Table (SSTable) data structure, based on the SSTable implementation in the open source Google LevelDB library. An SSTable is a file containing an immutable mapping of keys to values. Keys are stored in sorted order, with an index at the end of the file allowing keys to be located quickly. . mtbl is not a database library. It does not provide an updateable key-value data store, but rather exposes primitives for creating, searching and merging SSTable files. Unlike databases which use the SSTable data structure internally as part of their data store, management of SSTable files -- creation, merging, deletion, combining of search results from multiple SSTables -- is left to the discretion of the mtbl library user. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#661209: ITP: pymtbl -- immutable sorted string table library (Python bindings)
Package: wnpp Severity: wishlist Owner: Robert S. Edmonds * Package name: pymtbl Version : 0.1 Upstream Author : Internet Systems Consortium, Inc. * URL : https://github.com/edmonds/pymtbl * License : ISC Programming Lang: Cython Description : immutable sorted string table library (Python bindings) mtbl is a C library implementation of the Sorted String Table (SSTable) data structure. . This package contains a Python extension module for libmtbl. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On 2011-05-08, Martin Zobel-Helas wrote: > i currently wonder if Debian should implement RFC 4941 as default for > wheezy. > > Background: IPv6 configured via router advertisement will use the > hardware address of the ethernet card to encode the IPv6 address. This > raises privacy issues, such as being able to track each single device. > > I therefor wonder, if Debian should be shipped with the privacy > extensions for stateless address autoconfiguration on IPv6 per default > starting with wheezy. > > I would like to hear other developers meanings to this issue, before > proposing this as release goal for wheezy. it would be great if there were a simple way to control the IPv6 address selection policy (static, SLAAC, SLAAC + privacy extensions, DHCPv6...) from the interfaces(5) file or its successor. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/iqclgt$a74$1...@dough.gmane.org
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On 2011-05-11, Andrew O. Shadoura wrote: > On Wed, 11 May 2011 00:33:33 + (UTC) > Robert Edmonds wrote: > >> it would be great if there were a simple way to control the IPv6 >> address selection policy (static, SLAAC, SLAAC + privacy extensions, >> DHCPv6...) from the interfaces(5) file or its successor. > > It is and I hope we can get it into Debian (experimental?) soon. can you expand a bit on what 'it' is? (a package?) i would be kind of interested as to the 'correct' way of setting the 'static IPv6' policy on linux. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/iqvfsq$808$1...@dough.gmane.org
ITP: wrk -- HTTP benchmarking tool
Package: wnpp Severity: wishlist Owner: Robert Edmonds * Package name: wrk Version : 4.0.1 Upstream Author : Will Glozer * URL : https://github.com/wg/wrk * License : Apache-2.0, BSD-3-Clause Programming Lang: C Description : HTTP benchmarking tool wrk is a modern HTTP benchmarking tool capable of generating significant load when run on a single multi-core CPU. It combines a multithreaded design with scalable event notification systems such as epoll and kqueue. . An optional LuaJIT script can perform HTTP request generation, response processing, and custom reporting. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150415214452.ga19...@mycre.ws
Re: ITP: wrk -- HTTP benchmarking tool
Dmitry Smirnov wrote: > On Wed, 15 Apr 2015 17:44:52 Robert Edmonds wrote: > > * Package name: wrk > > Version : 4.0.1 > > Upstream Author : Will Glozer > > * URL : https://github.com/wg/wrk > > * License : Apache-2.0, BSD-3-Clause > > Programming Lang: C > > Description : HTTP benchmarking tool > > > > wrk is a modern HTTP benchmarking tool capable of generating significant > > load when run on a single multi-core CPU. It combines a multithreaded > > design with scalable event notification systems such as epoll and kqueue. > > . > > An optional LuaJIT script can perform HTTP request generation, response > > processing, and custom reporting. > > Any noticeable differences from "siege"? Thanks. Hi, Dmitry: One big difference is the LuaJIT scripting support in wrk. E.g., I believe with siege, the HTTP requests have to be constructed ahead of time (though there is support for variable expansion), whereas wrk can call a user-supplied Lua function to generate a request. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150417011620.ga1...@mycre.ws
Bug#786465: ITP: fstrm -- Frame Streams (fstrm) library
Package: wnpp Severity: wishlist Owner: Robert Edmonds * Package name: fstrm Version : 0.2.0 Upstream Author : Farsight Security, Inc. * URL : https://github.com/farsightsec/fstrm * License : Apache-2.0 Programming Lang: C Description : Frame Streams (fstrm) library Frame Streams is a light weight, binary clean protocol that allows for the transport of arbitrarily encoded data payload sequences with minimal framing overhead -- just four bytes per data frame. Frame Streams does not specify an encoding format for data frames and can be used with any data serialization format that produces byte sequences, such as Protocol Buffers, XML, JSON, MessagePack, YAML, etc. Frame Streams can be used as both a streaming transport over a reliable byte stream socket (TCP sockets, TLS connections, AF_UNIX sockets, etc.) for data in motion as well as a file format for data at rest. A "Content Type" header identifies the type of payload being carried over an individual Frame Stream and allows cooperating programs to determine how to interpret a given sequence of data payloads. . This is the "fstrm" implementation of Frame Streams in C. -- Robert Edmonds edmo...@debian.org pgpQZFT9ie9Hn.pgp Description: PGP signature
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Guillem Jover wrote: > In any case, barring better documentation or guides, using example > implementations simpler than glibc might be useful to people. So I > offer libbsd, but I'm sure there are many others. We could perhaps > even create a wiki page listing some of those pointers. libabc is a great example: http://0pointer.de/blog/projects/libabc.html -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150616152711.ga11...@mycre.ws
intent to package irquery
i intend to package irquery on www.ddns.org which is a client for their dynamic dns service. err they already had an rpm :) -- Robert S. Edmonds - Debian developerhttp://www.debian.org Freshmeat staff member http://freshmeat.net [EMAIL PROTECTED] / http://www.smart1.net/edmonds - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Anyone at Rice University?
Are there any Debian users/developers at Rice University in Houstin, Texas? My cousin came back home for summer vacation and I've set up his computer running Debian. However, it's got an Ethernet card (EtherLink III - set it up fine with the 3c509 module) and someone's going to have to set it up to use Rice's network when he gets back. He barely knows tcsh, unfortunately, I wonder if there are any Debian people at Rice that are familiar with the network to set it up for him. -- Robert Edmonds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
intent to package vstream/rtjpeg
i intend to package rtjpeg and vstream: rtjpeg is real time jpeg compressor with client/server mechanisms to allow running a BTTV card over a network using ~1/10 of 10BaseT bandwidth; and vstream is an app targeted at making mpeg movies from a BTTV stream. -- Robert Edmonds [EMAIL PROTECTED]
netcards (re: dwarf's etherlink3/isapnp idea)
I notice there is a great deal of diagnostic and setup utilities here: http://cesdis.gsfc.nasa.gov/linux/setup http://cesdis1.gsfc.nasa.gov/linux/diag/diagnostic.html When I have some spare time I think I'll set about to create a netcard configuration selector-type interface to all these utils, maybe package them up. A utility similar to modconf with netcard diagnostic tools would be very handy. -- Robert Edmonds [EMAIL PROTECTED] "The great question... which I have not been able to answer... is, `What does woman want?'" -- Sigmund Freud
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
The entire DNS root zone is only 1 MB compressed and is updated about once a day. It would be even better for privacy if the whole root zone were distributed via HTTPS, as the initiator would not reveal to the server any information about what TLD is being looked up. There are currently ~1500 TLDs in the root zone. Dividing 1 MB by the number of TLDs, this is ~700 bytes per TLD, which is roughly the amount of bandwidth required by a query/response pair of UDP DNS packets to obtain the delegation for a TLD. The size of the DNS root zone could also be reduced if it were signed by an ECC algorithm rather than RSA. If the ZONEMD resource record (draft-ietf-dnsop-dns-zone-digest) were standardized and deployed in the root zone, it would allow for cryptographic verification of the entire contents of the root zone regardless of the source. So it would not even be necessary to obtain the root zone from the "official" root name server infrastructure. That moves the problem down a level to the TLDs, where it is impracticable to distribute copies of all TLD zone files. So a better question to ask would be whether any of the DNS TLD servers plan to implement any of the DNS transport privacy options. That moves the problem down another level, etc. The benefit of encrypting the resolver to authoritative side of the DNS protocol is that it makes it possible to deploy "non stub" caching DNS resolvers to individual hosts without exposing the plaintext lookup traffic to either network observers or a centralized resolver operator such as an ISP or cloud provider. Ondřej Surý wrote: > DNSCurve - probably never > > DoT - the current profiles are stub to resolver, when they are profiles for > resolver to authoritative and a solid support in the software, the RSSAC will > surely talk about this. The deployment will have impact (switching all > traffics to TCP? Yay?) > > DoH - I am not sure what would be the benefit for resolver to authoritative, > but same as with DoT. > > DNSoQUIC - not yet there, but it might be better option for resolver to > authoritative... > > Ondřej > -- > Ondřej Surý > > > On 9 Sep 2019, at 03:17, Paul Wise wrote: > > > > On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote: > > > >> Mozilla plans to enable DoH to CloudFlare by default to US based users > > > > Does anyone know if there is any plan for the DNS root servers to > > enable any of the DNS privacy options? AFAIK the available options are > > DNSCurve, DoT or DoH. > > > > -- > > bye, > > pabs > > > > https://wiki.debian.org/PaulWise > > > -- Robert Edmonds edmo...@debian.org
Bug#1036538: ITP: emptty -- Dead simple CLI Display Manager on TTY
Package: wnpp Severity: wishlist Owner: Robert Edmonds * Package name: emptty Version : 0.10.0-1 Upstream Author : Michal Tvrznik * URL : https://github.com/tvrzna/emptty * License : Expat Programming Lang: Go Description : text-based display manager for starting graphical sessions emptty is a simple, text-based display manager for starting Wayland or Xorg sessions from a virtual console. It allows the user to interactively select a specific desktop environment or window manager to start and remembers the user's selection. The types of sessions that can be started can be configured system-wide or by the user. -- Robert Edmonds edmo...@debian.org
Bug#1039556: ITP: volare -- tiling, tabbed Wayland compositor based on Sway
Package: wnpp Severity: wishlist Owner: Robert Edmonds * Package name: volare Version : No releases yet Upstream Author : Arnout Engelen * URL : https://codeberg.org/raboof/volare * License : MIT Programming Lang: C Description : tiling, tabbed Wayland compositor based on Sway Volare is a tabbed, tiling Wayland compositor based on Sway, with modifications to make its window management behavior similar to that of the Notion window manager. Many tiling window managers are "dynamic", meaning they automatically change the tiling layout as windows appear and disappear. Volare's behavior is more static, keeping the user's existing tiling layout in place without automatically rearranging the tiling layout as application windows are created, moved, or destroyed. -- Robert Edmonds edmo...@debian.org
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
0.044177000 seconds sys If xzcat is restricted to a single core the performance is much worse (about 3.5 seconds for xz vs 0.5 seconds for zstd), although I understand from another post in the thread that dpkg performs multi-threaded xz decompression. This is on an ordinary "Intel(R) Xeon(R) E-2236 CPU @ 3.40GHz" CPU which is a four year old, 6 core, 12 thread processor. -- Robert Edmonds edmo...@debian.org
Re: Performance counter stats Was Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Lee wrote: > What did you do to get the "Performance counter stats" section in the > results for time? alias time="perf stat" -- Robert Edmonds edmo...@debian.org
Re: [RFC] locking down rsyslog.service
Michael Biebl wrote: > While the attempt is to secure the default configuration of rsyslog, I > do not want to restrict it so much that it becomes unusable. > If you think, that one of those directives could cause issues with > commonly used setups, please let me know, so I can adjust the > configuration. > > Looking forward to your feedback. Maybe also add `RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX`? I see the rsyslog package is compiled without capng support: --enable-libcap-ng Enable dropping capabilities to only the necessary set [default=no] With the libcap-ng dependency rsyslog can apparently perform capability privilege dropping at some point during startup: https://sources.debian.org/src/rsyslog/8.2308.0-1/tools/rsyslogd.c/#L1584-L1664 I seem to recall that capability dropping requires additional privileges, though (CAP_SETPCAP?). Is this code in rsyslog maybe redundant if the process starts up with the already reduced set of capabilities and that's the rationale for not building the package with --enable-libcap-ng? I guess if that's the case then there aren't any capabilities that are needed by rsyslog only briefly at startup that can be dropped by the daemon itself? -- Robert Edmonds edmo...@debian.org
Re: Limited security support for Go/Rust? Re ssh3
Simon Josefsson wrote: > Isn't that what the text refers to? Vendoring and static linking are > two examples of the same problem that the security team may encounter. > The problem with dependencies are more obvious for Go/Rust code but I > think we always have had that problem anyway. Another example of this class of problem is header only C++ libraries. -- Robert Edmonds edmo...@debian.org
Re: Validating tarballs against git repositories
Russ Allbery wrote: > Yes, perhaps it's time to switch to a different build system, although one > of the reasons I've personally been putting this off is that I do a lot of > feature probing for library APIs that have changed over time, and I'm not > sure how one does that in the non-Autoconf build systems. Meson's Porting > from Autotools [1] page, for example, doesn't seem to address this use > case at all. > > [1] https://mesonbuild.com/Porting-from-autotools.html Have a look at the documentation for the meson "compiler" object [1]. There is a lot of functionality in meson that has analogs in autoconf that isn't described in the "Porting from Autotools" document. [1] https://mesonbuild.com/Reference-manual_returned_compiler.html -- Robert Edmonds edmo...@debian.org
Re: xz backdoor
This backdoor abused the IFUNC mechanism in the GNU toolchain to hook into
the sshd process. Looking on my Debian sid workstation with about 1900 library
packages installed, I see a very small handful of source packages shipping
libraries with IFUNC symbols, mostly things like gcc, glibc, haskell, some Intel
GPU stuff, etc. [0]
I do not know enough about the underlying technology to guess why the attacker
chose to abuse the IFUNC mechanism versus, say, using the ELF .init_array
section to introduce an ordinary initialization function into the backdoor
library. (E.g., putting the equivalent of an __attribute__((constructor))
function in the compiled binary blob part of the backdoor.) Perhaps what the
attacker wanted to do was much easier to implement with the IFUNC mechanism to
the point that it justified the sourceful changes to the upstream repository.
If IFUNC symbols are sufficiently rare and sufficiently powerful, is it
worth implementing some hygiene around their proliferation in Debian? For
instance, something like a Lintian tag combined with an ftpmaster autoreject,
such as what we do for libraries that set RPATH?
[0] A quick and dirty way to check for IFUNC symbols in the libraries installed
on the system:
for fname in /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/*.so.*; do
echo "> ${fname} <"
readelf -X -s ${fname} | grep IFUNC
echo
done
--
Robert Edmonds
edmo...@debian.org
Re: Is missing SysV-init support a bug?
Guus Sliepen wrote: > On Fri, Aug 26, 2016 at 12:11:13AM +0200, Sven Hartge wrote: > > > I just saw the new conntrack-tools (1:1.4.4-2) package in Sid, which > > has as a change > > > > * [917beed] conntrackd: get rid of the sysvinit support > > > > and I wondered, if this is a bug (and at what severity) or not. > > Yes, this is a bug and I think you can give it at least priority important. > While Debian has switched to systemd as the *default* init system, it is > not the only one it supports. Package maintainers should not remove > support for other init systems. If they feel they are not up to > maintaining the sysvinit scripts, they should ask for help instead of > removing them. I looked up the answer to this recently (because I wanted to do exactly what the conntrackd maintainer had done). The relevant text from the policy manual, §9.11: Packages may integrate with these replacement init systems [i.e., init systems which are not sysvinit] by providing implementation-specific configuration information about how and when to start a service or in what order to run certain tasks at boot time. However, any package integrating with other init systems must also be backwards-compatible with sysvinit by providing a SysV-style init script with the same name as and equivalent functionality to any init-specific job, as this is the only start-up configuration method guaranteed to be supported by all init implementations. The relevant TC decision was two years ago in #746715: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. (https://lists.debian.org/debian-devel-announce/2014/08/msg1.html) However, that was two years ago. How long should we be expected to continue maintaining sysvinit scripts? -- Robert Edmonds edmo...@debian.org
Re: Is missing SysV-init support a bug?
Russ Allbery wrote: > Robert Edmonds writes: > > > However, that was two years ago. How long should we be expected to > > continue maintaining sysvinit scripts? > > My understanding of the feeling of the TC at the time is that maintainers > are expected to continue including the sysvinit scripts for as long as (a > reasonable number of) folks are using sysvinit with Debian and keeping it > working, a bar that I think is still being easily met. I would guess that the vast majority of folks still using sysvinit with Debian are running wheezy or older, and thus removing sysvinit scripts from packages in unstable wouldn't affect them. But maybe that still leaves a reasonable number of testing/unstable + sysvinit users. > Note that "continue maintaining" is a bit strong; if you don't use > sysvinit and don't have any sysvinit systems, I don't think you're > expected to spin up a test system just to be sure things don't break. But > the ask was to not explicitly yank support (that isn't unfixably broken) > and to merge reasonable fixes, and of course like any packaging quality > issue the more that you're willing to do, the more awesome that makes > Debian for sysvinit users. Ah, OK. I count merging fixes as part of maintaining, so that seems like a fine distinction to me :-) -- Robert Edmonds edmo...@debian.org
Re: Is missing SysV-init support a bug?
Carsten Leonhardt wrote: > Robert Edmonds writes: > > > I would guess that the vast majority of folks still using sysvinit with > > Debian are running wheezy or older, and thus removing sysvinit scripts > > from packages in unstable wouldn't affect them. But maybe that still > > leaves a reasonable number of testing/unstable + sysvinit users. > > Considering the past conflicts on the topic of systemd, it should be > expected that there is a considerable user base that is staying with > sysvinit or another alternative. Why should it be expected? Is email activity on a given topic more or less representative than popcon statistics? -- Robert Edmonds edmo...@debian.org
Re: When should we https our mirrors?
Tollef Fog Heen wrote: > ]] Paul Tagliamonte > > > So, when are we going to push this? If not now, what criteria need to > > be met? Why can't we https-ify the default CDN mirror today? > > The usual crypto answer: because key handling is hard. > > Doing this for the per-country mirrors means that repointing mirrors > becomes a lot harder than it currently is, and this is something we do > on a daily basis. We'd need a solution for deploying the TLS cert for, > say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for > maintenance. > > Doing this for deb.d.o would mean we need to get certs on both Fastly > and Cloudfront deployed, which is, frankly, a more realistic proposition > than jury-rigging something on the per-country mirrors. Hi, Since the Debian project controls the mirror client (in particular the code responsible for performing certificate validation), surely there is some way we can engineer our way to a less painful solution? We don't have to imitate the way web browsers or other HTTP clients perform certificate validation, right? We currently use DNS SRV records for a few mirror domains to direct apt traffic, e.g. for ftp.us.debian.org: ;; QUESTION SECTION: ;_http._tcp.ftp.us.debian.org. IN SRV ;; ANSWER SECTION: _http._tcp.ftp.us.debian.org. 3600 IN SRV 0 1 80 ftp-chi.osuosl.org. _http._tcp.ftp.us.debian.org. 3600 IN SRV 0 2 80 ftp-nyc.osuosl.org. _http._tcp.ftp.us.debian.org. 3600 IN SRV 0 1 80 debian.gtisc.gatech.edu. If there were some way to be able to trust the SRV target names (the right-most names in the above output like "debian.gtisc.gatech.edu", which tend to be very stable since they're chosen by the mirror operator), we could use those names as the domain name in the TLS certificate to be validated by apt, and it would be easy for a mirror operator to go off and acquire a TLS certificate for the "canonical" name of their server, rather than the .debian.org alias. Unfortunately, the data in the SRV records comes from the DNS, and even though the debian.org zone is signed, we cannot currently rely on DNSSEC validation occurring (and occurring successfully) on every Debian system running apt. Some possibilities: 1) Maybe we could securely distribute the list of canonical mirror names via security.debian.org (using traditional certificate validation rules), either in a package or in metadata stored in the archive? 2) Maybe we could constrain apt so that it would use the (untrusted) DNS SRV target names for certificate validation only if the names were rooted in a base domain name on a whitelist? E.g., if the SRV target name ends in "._tls-servers.debian.org", then that name can be used as the name to be validated in the TLS certificate. Then we could set up SRV RRs that use aliased mirror hostnames like this: _https._tcp.ftp.us.debian.org. SRV 0 1 443 ftp-chi.osuosl.org._tls-servers.debian.org. _https._tcp.ftp.us.debian.org. SRV 0 2 443 ftp-nyc.osuosl.org._tls-servers.debian.org. _https._tcp.ftp.us.debian.org. SRV 0 1 443 debian.gtisc.gatech.edu._tls-servers.debian.org. and then alias those target names to the canonical mirror hostnames: ftp-chi.osuosl.org._tls-servers.debian.org. CNAME ftp-chi.osuosl.org. ftp-nyc.osuosl.org._tls-servers.debian.org. CNAME ftp-nyc.osuosl.org. debian.gtisc.gatech.edu._tls-servers.debian.org. CNAME debian.gtisc.gatech.edu. Then the operator of debian.gtisc.gatech.edu only has to go off and set up a vhost for "debian.gtisc.gatech.edu._tls-servers.debian.org" in the mirror server's HTTP config, and acquire a TLS certificate for that name. Both of these options have the problem that a potential MITM can just become a rogue mirror operator, but perhaps more fine-grained constraints could be defined, or we could require the same level of trust for HTTPS mirror operators that we do for new maintainers (i.e., PGP signatures from two active developers)? -- Robert Edmonds edmo...@debian.org
Re: Suddenly U2F doesn't work on sid
Hideki Yamane wrote: > Hi, > > Today, I've tried to login salsa.debian.org, 2FA doesn't work well > (and on github, too). It works several days ago. > > The message on salsa is > >>There was a problem communicating with your device. (error code: 1) > > On my desktop (sid) > - chrome / chromium / chrome-unstable doesn't work > - with other user account, it doesn't work, too > - tried to use another U2F device, both of them don't work > - boot with Fedora27, it works (so, it's not hardware issue, IMO) > > On my laptop (sid) > - chrome / chromium works > > Now I can login to salsa on my laptop, but I usually do my work on > desktop, so I want to solve it. > > Both of them run Debian sid and updated. > Any suggestions, or ideas? Hi, Hideki: I ran into the same problem. It looks like it was due to #889665 being fixed and not having the libu2f-udev package installed. -- Robert Edmonds edmo...@debian.org
Bug#870571: ITP: avro-c -- Apache Avro C
Package: wnpp Severity: wishlist Owner: Robert Edmonds * Package name: avro-c Version : 1.8.2 Upstream Author : The Apache Software Foundation * URL : http://avro.apache.org/ * License : Apache-2.0 Programming Lang: C Description : Apache Avro C (avro-c) library Apache Avro is a data serialization system. Avro provides rich data structures; a binary data format; and a container file format, to store Avro-encoded data persistently. . This package provides the "avro-c" implementation of Apache Avro in C. The C implementation supports: . * binary encoding/decoding of all primitive and complex data types * storage to an Avro Object Container File * schema resolution, promotion and projection * validating and non-validating mode for writing Avro data . The C implementation of Avro lacks RPC support. -- Robert Edmonds edmo...@debian.org signature.asc Description: PGP signature
Re: bind9 shipping outdated root hint file (etc.)
Chris Lamb wrote: > It was just mentioned "en passant" in a conversation at DebConf that > bind9 is shipping a root hint file from 2003. No, this is just wrong. The hints file shipped in the bind9 package in stretch is from 2016: ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC ; under anonymous FTP as ; file/domain/named.cache ; on server FTP.INTERNIC.NET ; -OR-RS.INTERNIC.NET ; ; last update:February 17, 2016 ; related version of root zone: 2016021701 […] There are now 26 root server addresses, and root servers are renumbered slowly enough that the normal Debian release process is more than adequate for keeping up with those renumbering events. Over the past decade or more the DNS root server network has added IPv6 addresses, and has renumbered out of network prefixes used by larger networks into network prefixes dedicated solely to root DNS service. So my guess is that renumbering events will become even more rare over time. The consequences for having an out-of-date root hints file are fairly minimal. All modern recursive DNS servers employ a "priming" technique where the initial hints list is used to obtain the latest set of root server addresses at server startup. See RFC 8109, "Initializing a DNS Resolver with Priming Queries". An up-to-date set of root hints is shipped in the dns-root-data package, but I believe only a few DNS software packages have been updated to take advantage of it. Some DNS servers also embed a copy of root server addresses in compiled binaries as a hedge against missing or obsolete hints files, and this practice is fine as long as the upstream developers keep that list up-to-date and make regular releases. Priming will ensure that those binaries obtain an up-to-date set of addresses at startup. The only package in the archive that I know of that has a seriously deficient set of root hints is djbdns; it has 11/13 of the current set of IPv4 root server addresses, and 0/13 IPv6 root server addresses. (However, I don't believe the 'djbdns' binary package ships with the IPv6 patch applied.) > I had a quick glance at the bug list and saw it was a little larger > than I would have liked for what is clearly a critical piece and > infrastructure. :) It may have been true in 2003 that bind9 was a critical piece of DNS infrastructure for Linux distributions, but it has become much less true over time: there are multiple, modern implementations of authoritative and recursive DNS servers in the Debian archive today. On the recursive side: PowerDNS Recursor, Knot Resolver, and Unbound. On the authoritative side: Power DNS Authoritative, Knot DNS, and NSD. -- Robert Edmonds edmo...@debian.org
RFH: protobuf packaging team formed
Hi, I'm announcing the formation of the Debian protobuf packaging team that will be responsible for packaging the src:protobuf package. (And maybe closely related packages like src:grpc, if the maintainers are interested.) Iustin Pop has maintained src:protobuf in the past, and I've maintained it through the 2.5.x and 2.6.x upstream releases, but I don't have much time to devote to it in the near future, so after receiving mail from several developers interested in helping package the upcoming 3.x release I'm turning it over to a team. Anyone interested in helping to package the upcoming upstream 3.x releases is welcome to join the Alioth group and mailing list: https://alioth.debian.org/projects/pkg-protobuf/ https://lists.alioth.debian.org/mailman/listinfo/pkg-protobuf-devel The upcoming 3.x release has gotten more complicated to package, mostly through the addition of new language bindings. It also introduces a new backwards-incompatible language syntax "proto3", while still supporting the deprecated "proto2" syntax. Upstream says the following about proto3 vs proto2: We recommend that new Protocol Buffers users use proto3. However, we do not generally recommend that existing users migrate from proto2 from proto3 due to API incompatibility, and we will continue to support proto2 for a long time. Upstream doesn't specify exactly how long proto2 will be supported, but if proto2 language support is removed from a future protobuf version, it may cause problems for some of the packages listed below. The TODO list is: - Ack the src:protobuf NMUs (2.6.1-1.1, -1.2, -1.3) by committing them to the repo. - Figure out what to do about the semi-embedded gmock/gtest build dependency. Related upstream issues: https://github.com/google/protobuf/issues/302 https://github.com/google/protobuf/issues/808 - Figure out how to package the new language bindings in protobuf 3. protobuf has a number of reverse dependencies in the archive, including: anfo bitcoin-qt clementine cubemap emacs-mozc-bin fcitx-mozc gazebo5 gazebo5-plugin-base ibus-mozc libanfo0 libgazebo5 libignition-transport0 libola1 libphonenumber6 libshogun16 litecoin-qt mahimahi monav-preprocessor mosh mozc-server mozc-utils-gui mumble mumble-server ola osrm ostinato php5-pinba pink-pony pokerth pokerth-server protobuf-c-compiler python-imposm python-imposm-parser python-protobuf shogun-cmdline-static uim-mozc zbackup (This is just a list of rdeps on libprotobuf9 or libprotobuf9v5, IIRC there are some source packages that have build-deps on protobuf that don't appear as binary deps.) protobuf is implemented in C++ and has frequent ABI bumps. The transitions tend to be fairly involved, see the bug logs for the last two transitions for details: https://bugs.debian.org/726165 https://bugs.debian.org/760343 There are some interesting projects that depend on Protocol Buffers, such as Canonical's Mir and Google's gRPC. The OpenStreetMap project also has a binary "PBF" format that uses protobufs. (IIRC, protobufs are also used in some of Canonical's web services.) If you are involved in packaging those projects, you might want to look into helping out with packaging src:protobuf. Thanks! -- Robert Edmonds edmo...@debian.org
Re: DAK Commands for Bikesheds
Wookey wrote:
> +++ Raphael Hertzog [2015-09-17 14:41 +0200]:
> > Hi,
> >
> > On Thu, 17 Sep 2015, Joerg Jaspert wrote:
> > > Please check if I forgot something obvious or if there is some big error
> > > in it. Patches/git trees to merge from/... are welcome.
> >
> > Please don't call this feature "Bikesheds" and don't hardcode this naming
> > in the suggested API. It was funny during one Debconf talk... but it won't
> > be funny in the long term.
>
> It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> the unix tradition of mildly amusing/punny names.
Which tradition would that be?
Out of the few hundred or so Unix [0] and GNU [1] commands listed on
Wikipedia, the only vaguely amusing/punning names I can find are tac
("cat" backwards) and pinky (a lightweight "finger").
[0] https://en.wikipedia.org/wiki/List_of_Unix_commands
[1] https://en.wikipedia.org/wiki/GNU_Core_Utilities
RFC 1178 ("Choosing a Name for Your Computer", a reprint from a CACM
article) has some good advice about picking hostnames. Some of it is
applicable to picking names for software, too, including:
[...]
Don't overload other terms already in common use.
Using a word that has strong semantic implications in the
current context will cause confusion. This is especially true
in conversation where punctuation is not obvious and grammar is
often incorrect.
For example, a distributed database had been built on top of
several computers. Each one had a different name. One machine
was named "up", as it was the only one that accepted updates.
Conversations would sound like this: "Is up down?" and "Boot
the machine up." followed by "Which machine?"
While it didn't take long to catch on and get used to this
zaniness, it was annoying when occasionally your mind would
stumble, and you would have to stop and think about each word
in a sentence. It is as if, all of a sudden, English has
become a foreign language.
[...]
Don't use antagonistic or otherwise embarrassing names.
Words like "moron" or "twit" are good names if no one else is
going to see them. But if you ever give someone a demo on your
machine, you may find that they are distracted by seeing a
nasty word on your screen. (Maybe their spouse called them
that this morning.) Why bother taking the chance that they
will be turned off by something completely irrelevant to your
demo.
[...]
Use words/names that are rarely used.
While a word like "typical" or "up" (see above) isn't computer
jargon, it is just too likely to arise in discussion and throw
off one's concentration while determining the correct referent.
Instead, use words like "lurch" or "squire" which are unlikely
to cause any confusion.
You might feel it is safe to use the name "jose" just because
no one is named that in your group, but you will have a problem
if you should happen to hire Jose. A name like "sphinx" will
be less likely to conflict with new hires.
[...]
--
Robert Edmonds
edmo...@debian.org
Re: DAK Commands for Bikesheds
Lucas Nussbaum wrote:
> On 17/09/15 at 15:04 -0400, Robert Edmonds wrote:
> > Wookey wrote:
> > > +++ Raphael Hertzog [2015-09-17 14:41 +0200]:
> > > > Hi,
> > > >
> > > > On Thu, 17 Sep 2015, Joerg Jaspert wrote:
> > > > > Please check if I forgot something obvious or if there is some big
> > > > > error
> > > > > in it. Patches/git trees to merge from/... are welcome.
> > > >
> > > > Please don't call this feature "Bikesheds" and don't hardcode this
> > > > naming
> > > > in the suggested API. It was funny during one Debconf talk... but it
> > > > won't
> > > > be funny in the long term.
> > >
> > > It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> > > the unix tradition of mildly amusing/punny names.
> >
> > Which tradition would that be?
> >
> > Out of the few hundred or so Unix [0] and GNU [1] commands listed on
> > Wikipedia, the only vaguely amusing/punning names I can find are tac
> > ("cat" backwards) and pinky (a lightweight "finger").
>
> seriously?
> apt, aptitude, bash, bison (yacc replacement), curl, curses, flex, gawk,
> glut, grub, lame, less, mutt, sane, tar, vim are all project names that
> I find at least vaguely amusing.
Ah, OK, I was mostly thinking of names from the early Unix era. Puns
did certainly creep into the GNU and later eras, e.g., yacc -> bison,
more -> less -> most. I guess curses -> ncurses was a missed
opportunity.
Some names originally intended to be amusing have not stood the test of
time, though. E.g., "BitchX", "GIMP"...
> However we can probably find something more amusing and less loaded than
> 'Bikeshed' for the project being discussed.
Indeed, and it's interesting that you mention apt and aptitude. APT
originally had a somewhat unsettling name and after some debate a much
better name was agreed upon. In fact, re-reading those threads I see
some of the same arguments being made here. APT then went on to
arguably become even more popular than Debian itself.
--
Robert Edmonds
edmo...@debian.org
Re: DAK Commands for Bikesheds
Hi, Philip Hands wrote: > Colin Tuckley writes: > > > On 18/09/15 22:23, Joerg Jaspert wrote: > > > >> what the heck bikesheds are. > > > > What you seem to not be understanding, possibly because English is not > > your first language, is that anything associated with the term > > 'bikeshed' is very *negative*. > > > > They have strong derogatory connotations, so much so that I doubt any > > native English speaker will be interested in them. > > Utter nonsense ... or are you trying to claim that Steve, Wookey, Neil, > Paul and I are not native English speakers now? > > I dispute your claim that "bikesheds", as opposed to "bikeshedding", is > negative -- if it were, we'd store our velocipedes in the cycle lock-up. Not *all* things described as "bike sheds" take on the derogatory connotation. For instance, as in your example, an actual shed used to store actual bikes is taking on a purely descriptive and non-pejorative meaning when called a "bike shed". Forgive me for making this very obvious point. However, there is no effective distinction between "bike shed" (n., v., or adj.) and "bikeshedding" when used metaphorically in the context of software development. In fact, the word "bikeshedding" does not even appear in the famous essay (http://phk.freebsd.dk/sagas/bikeshed.html, and note the mirrors at http://bikeshed.org/ and http://shed.bike/ whose URLs also use the "-ing"'less form.) ...and, did anyone notice that the actual commands [0] abbreviate "bikeshed" to "bs" (why? is there a length limit?)? Which has a euphemistic meaning which is much more widely known than "bikeshed" and which is far more pejorative. [0] https://ftp-master.debian.org/users/joerg/README.commands -- Robert Edmonds edmo...@debian.org
Re: [ralph.amis...@gmail.com: outrageous, thievery]
are others that know him pretty well, who have followed a fairly > >> long sequence of events who must be outraged as well. > >> > >> Of course I wish Debian well, but I do not see your "handling" of Daniel > >> as its finest hour. This will no doubt "blow over" as it must ultimately > >> for the good of the project, but it sticks in my craw as it no doubt > >> does others, and there should be some record of conscientious objection. > >> > >> Ralph Amissah > >> > >> [1] to be clear, "we" was Debian. > >> [2] http://www.sisudoc.org/ > >> https://qa.debian.org/developer.php?login=s...@lists.sisudoc.org > >> > >> > > > > > > -- > > CONFIDENTIALITY NOTICE: This electronic communication with its contents > > may contain confidential and/or privileged information. It is solely for > > the use of the intended recipient(s). Unauthorized interception, review, > > use, or disclosure is prohibited and may violate applicable laws including > > the Electronic Communications Privacy Act. If you are not the intended > > recipient, or authorized to receive for the intended recipient, please > > contact the sender and destroy all copies of the communication. Thank you > > for your consideration. > > -- Robert Edmonds edmo...@debian.org
Re: vixie-cron small patch
Stanislav Zaharov wrote: > Hello everybody! > I've added new environment support to vixie-cron which is used by default > cron in Debian. This environment is adding oppotunity to set mail subject > for cron's report. It looks like this: > MAILSUBJECT="CRON at the %hostname% (fqdn: %fqdn%): User %user% ran command > %cmd% which was executed with status %status%. Cron fork status: > %forkstatus%" > * * * * * root echo test > > It can be useful for many users. I've attached the patch for vixie cron. > Could the patch be included to Debian release? Hi, Stan: Have you tried getting your patch merged upstream? (Just kidding, it looks like Debian hasn't pulled a new upstream release of cron in about 22 years, and new upstream releases are... infrequent.) More seriously, any C code that manipulates strings should be heavily scrutinized, especially in a security sensitive daemon like cron, which has had a history of security vulnerabilities, some of which were introduced by later patches to the original code. There are static analyzers that can help with this, e.g. Clang's scan-build (free), and Coverity (non-free). But, maybe it would be better to freeze the user-facing functionality of a venerable tool like cron? This seems like kind of a disruptive change. -- Robert Edmonds edmo...@debian.org
Bug#808410: RFA: re2c -- tool for generating fast C-based recognizers
Package: wnpp Severity: normal Hi, I'm requesting an adopter for the re2c package. The package description is: re2c is a great tool for writing fast and flexible lexers. Unlike other such tools, re2c concentrates solely on generating efficient code for matching regular expressions. Not only does this singleness make re2c more suitable for a wider variety of applications, it allows us to generate scanners which approach hand-crafted ones in terms of size and speed. Note that re2c is a dependency for spamassassin's sa-compile package. Thanks! -- Robert Edmonds edmo...@debian.org
Re: Automatic dbgsym packages built by default as of today!
Paul Wise wrote: > On Sun, Dec 20, 2015 at 10:07 AM, Christoph Anton Mitterer wrote: > > > Will this eventually replace all the existing -dbg packages? > > That is the plan, yes. > > > And will this eventually become part of normal unstable/testing/etc. > > and mirrors, or is it intended that people really always add e.g. > > unstable-debug? > > The latter. Are the *-debug suites going to stay in a separate repository? If so, is a separate mirror network being set up? I help maintain a public mirror of the 'debian' repository, and if possible I'd like to setup a mirror of the 'debian-debug' repository as well. -- Robert Edmonds edmo...@debian.org
Re: support for merged /usr in Debian
Simon McVittie wrote: > 0m24.5s DEBUG: Starting command: ['adequate', '--root', > '/srv/piuparts.debian.org/tmp/tmpk5ZNdX', 'iputils-ping'] > 0m24.6s DUMP: > iputils-ping: bin-or-sbin-binary-requires-usr-lib-library /bin/ping6 > => /usr/lib/x86_64-linux-gnu/libgnutls-openssl.so.27 > > I don't know why a ping implementation wants to do SSL, but let's assume > that's a useful thing to do for some reason. Are you saying that GNUTLS > and all its dependencies should move from /usr to /? Looks like it's not actually SSL that ping6 wants to do, but MD5, due to the support for "ICMPv6 Node Information Queries (RFC4620)": https://tools.ietf.org/html/rfc4620#section-5 [...] Compute the MD5 hash [...] If it really does need to do MD5, maybe it could use the one in libbsd0 instead of dragging in libgnutls-openssl27 and its dependencies. -- Robert Edmonds edmo...@debian.org
Re: Gitlab and the BTS (was Re: Genesis of the git.d.o/gitlab.d.o confusion)
Jonathan Dowland wrote: > I was wondering what the Gitlab proponent's thoughts are on how the Issue > tracker functionality of Gitlab should be used in a Debian context, > particularly in how it might intersect/interact/conflict with the BTS. Also note that GitLab merge requests are numbered (I think the GitLab markdown extension syntax is !1, !2, etc.), and it wouldn't be unlikely to see such references in Debian changelogs. -- Robert Edmonds edmo...@debian.org
Re: OpenSSL 1.1.0
Kurt Roeckx wrote: > Robert Edmonds >unbound (U) Thanks. Opened a bug report with upstream: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=777 -- Robert Edmonds edmo...@debian.org
Re: OpenPGP certificates with SHA-1 issues in Debian keyrings
Guillem Jover wrote:
> Hi!
>
> A recent dupload improvement to switch from its GnuPG based OpenPGP
> verification hook to use the dpkg OpenPGP multi-backend
> implementation, which as a side effect got rid of a very old code path
> that was ignoring some GnuPG verification failures, resurfaced an old
> known problem with OpenPGP certificates with SHA-1 issues in the
> Debian keyrings.
>
> Not all of these issues are equally "bad" from a Debian point of view,
> but all are probably bad for the certificate owners, as it might imply
> that people cannot verify signatures made with those certificates. In
> the Debian context that might mean emails, or signatures on artifacts
> such as .dsc or .changes. Depending on the specific problem those
> might even cause rejects from DAK.
>
> I filed #1100734 against debian-keyring the other day, but to try to
> help people that might get confused by the kind or errors that dupload
> (or dpkg-source --require-valid-signature or dscverify) might be
> emitting (I think dput-ng is strict with its OpenPGP verification and
> should have already been rejecting signatures from those certificates,
> although I think dput might be lenient as dupload used to be and might
> let those through (?)), I've prepared a list of affected certificates
> per keyring, which I'm attaching.
>
> To check for the exact issues you can use the Sequoia certificate
> linter (from the «sq» package) with something like:
>
> $ sq cert lint --cert FINGERPRINT
>
> To fix your certificate it should (in theory) be enough to do:
>
> $ sq cert lint --cert FINGERPRINT --fix | gpg --import
>
> (Given that Sequoia can transparently read from the GnuPG certstore,
> and talk to gpg-agent.)
>
> You might want to check the chapter for that at
> <https://book.sequoia-pgp.org/lint.html>. If you'd prefer to use GnuPG
> to fix your certificate, although in a really more tedious way, you can
> follow these instructions instead:
>
>
> https://lore.kernel.org/keys/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/T/#u
>
> (I'm also attaching the script I used to generate the lists.)
>
> Thanks,
> Guillem
> Fingerprint: DF3D96EEB3827820F302665C01817AB0AAF6CDAE
>UserID: Robert Edmonds
>UserID: Robert Edmonds
>UserID: Robert Edmonds
Hello,
I'm not sure this analysis is completely correct. As far as I can tell,
you've flagged my key on the basis of "sq cert lint" reporting the
following output:
$ sq cert lint --keyring /usr/share/keyrings/debian-keyring.gpg --cert
01817AB0AAF6CDAE
Certificate 01817AB0AAF6CDAE, key 292C9BB54A4D3CBA uses a SHA-1-protected
binding signature.
Examined 1 certificate.
0 certificates are invalid and were not linted. (GOOD)
1 certificate was linted.
1 of the 1 certificates (100%) has at least one issue. (BAD)
0 of the linted certificates were revoked.
0 of the 0 certificates has revocation certificates that are weaker than
the certificate and should be recreated. (GOOD)
0 of the linted certificates were expired.
1 of the non-revoked linted certificate has at least one non-revoked User
ID:
0 have at least one User ID protected by SHA-1. (GOOD)
0 have all User IDs protected by SHA-1. (GOOD)
1 of the non-revoked linted certificates has at least one non-revoked, live
subkey:
1 has at least one non-revoked, live subkey with a binding signature that
uses SHA-1. (BAD)
0 of the non-revoked linted certificates have at least one non-revoked,
live, signing-capable subkey:
0 certificates have at least one non-revoked, live, signing-capable
subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
Error: 1 certificate have at least one issue
Now, key 292C9BB54A4D3CBA is my encryption subkey, not the main key
01817AB0AAF6CDAE that is used for signing and certifying:
sec rsa4096/01817AB0AAF6CDAE
created: 2013-10-03 expires: never usage: SC
card-no: 0005 3A89
trust: ultimate validity: ultimate
ssb rsa4096/292C9BB54A4D3CBA
created: 2013-10-03 expires: never usage: E
card-no: 0005 3A89
Since only the encryption subkey is affected, I do not believe this
problem can affect the signatures on my signed .dsc or .changes files.
Here are the raw PGP packets, from a clean sid chroot with gpg and
debian-keyring installed:
root@7311057f397a:/# gpg --keyring=/usr/share/keyrings/debian-keyring.gpg
--export-options export-minimal --export 01817AB0AAF6CDAE | gpg --list-packets
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
version 4, algo 1, created 1380802569, expires 0
pkey[0]: [4096 bits]
Re: Bug#1094969: git linked with OpenSSL
Russ Allbery wrote:
> I think the situation here is this dependency chain:
>
> libcurl-gnutls -> libldap2 -> libssl
>
> (There may be others; I didn't do a thorough check. Does anyone know if
> there's a tool that will recursively analyze a binary's NEEDED sections
> and build a human-readable graph of the library dependencies?)
I see the following with "libtree -vvv" (output trimmed by hand to just
the paths to libcrypto or libssl):
/usr/lib/git-core/git-remote-https
├── libcurl-gnutls.so.4 [ld.so.conf]
│ ├── libldap.so.2 [ld.so.conf]
│ │ ├── libcrypto.so.3 [ld.so.conf]
│ │ ├── libssl.so.3 [ld.so.conf]
│ │ └── libsasl2.so.2 [ld.so.conf]
│ │ ├── libcrypto.so.3 [ld.so.conf]
│ ├── libssh2.so.1 [ld.so.conf]
│ │ ├── libcrypto.so.3 [ld.so.conf]
--
Robert Edmonds
edmo...@debian.org
