Re: Changes in the maintenance of the Developers Reference
On Mon, Sep 21, 2009 at 01:40:51PM +0200, Bill Allombert wrote: > Debian Policy has a more formal process than developers-reference and > I am concerned that mixing both discussions on the same channel would cause > confusion. > > debian-de...@l.d.o could be a better channel for the developers-reference > discussions, though with the downside of yet more outside traffic than > debian-policy. The whole point of moving the devref to -policy@ was so that policy amendments that belong more in the devref (and vice versa) could easily be redirected. That advantage is lost if devref discussions were to be moved to -de...@. If you fear there will be confusion, it's probably best to make some minor changes to the devref process so that there will not be confusion. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
* Philipp Kern: > On 2009-09-21, Hilko Bengen wrote: >> I have written and maintained scripts that download signature file >> updates for several commercial antivirus scanners and built packages for >> them -- which is pretty much the same thing that clamav-getfiles does. >> 10 updates to the signature files per day are not uncommon in the >> proprietary space and I'd be very surprised if things were any different >> for ClamAV. > > Well, there was also the problem that when asked what problem it tries to > solve nobody came up with something sane. So, you see no use-case for which it would be worth to support clamav-data? What about a geoip-data package? What are the criteria that need to be met? > If boxes have no internet access freshclam could ask through a proxy, > or similar. So I guess the usecase is really that you shut off your > machines from the internet, only able to access internal hosts and the > packaging mirror to fetch the signatures from? How is that different > from just setting up a signature mirror on an internal host? If AV signatures and other data files are made available through the archive infrastructure administrators of such setups are saved from having to do extra error-prone work for each application that relies on current data files. To me, the main point of using a Debian's distribution mechanism is that I can avoid having to do stuff _manually_. As long as I can trust the involved parties (package maintainers, the ftp team, the security team, etc.) to do a better job than I could on my own, I am happy to use their work. Which is fine. Setting up a local mirror for some data files may seem little work at first, but every time your homegrown mirroring mechanism breaks, you will need to put in more effort into fixing it. If you take your job seriously, you will want to implement proactive checks for the mirroring mechanism so an alarm is raised if the network connection fails or if the mirroring software decides to download garbage etc.. Suddenly, you have to put in a lot of effort for a problem that was solved with the first release of apt. And you'd have to do the same kind of work for every application that needs constant updating in order to remain useful. Sounds like fun, doesn't it? Yes, I am lazy to a certain degree because avoiding to work on uninteresting, repetitive tasks that have been solved before by smart people leaves more time for me to spend on interesting things. I find this kind of prioritizing quite sane. :-) And I'd expect many Debian users to think along similar lines. -Hilko -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547804: RFH: stfl -- structured terminal forms language/library
Package: wnpp Severity: normal I request assistance with maintaining the stfl package. The package description is: stfl is a library which implements a curses-based widget set for text terminals. . This package contains the development files required to build software that uses libstfl. I currently lack of time and interest to properly maintain the package but I don't want to orphan it yet. Therefore I am searching for a new co-maintainer for this package. The biggest todo would be to package the new upstream release. Kind regards Nico -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Quick analysis of the Python dist-packages transition
Le vendredi 18 septembre 2009 à 21:18 +0200, Josselin Mouette a écrit : > If there are no objections, I will submit a MBF for those 75 packages in > a few days. Done, omitting a reported false positive and a few packages fixed in the meantime. http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-pyt...@lists.debian.org;tag=python2.6 -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: opposition against clamav-data in debian volatile
2009/9/20 Henrique de Moraes Holschuh : > On Sun, 20 Sep 2009, Marc Haber wrote: >> As long as you do not expect me to manually sign every single upload, > > Why not? It is a package, it has root access anywhere it is being installed > or removed. Even if you abuse the DM machinery to have a key restricted to > only upload clamav-data, it would still be risky. As you said, you'd have > to jump through a lot of loops to do special validation of that specific > package before installing it. This really sounds like there is a "use case" for data-only "packages" that: - do not include maintainer scripts (dpkg refuses to run them) or are only allowed a set of limited tasks (run in a restricted shell or with reduced privileges) - are only allowed to write in a specific place on disk (such as /var/lib/) Wouldn't that reduce the problems surrounding clamav-data and other frequently-updated data packages? Maybe that's something that could be taken on board by dpkg maintainers? As (co-)maintainer of other security software which relies on frequent data updates (Snort, Nessus/OpenVAS), I believe that most admins and users now understand that for software to be effective the associated security data provided in packages (such as that used by ClamAV, Snort or Nessus/OpenVAS) requires an Internet connection. And frequent updates are needed through the use of upstream's custom services and tools. IMHO data packages for this kind of software should be used only to provide way for users to have a limited feature-set so that the software isn't inmediatley useless after installation if they don't have an Internet connection readily available. Of course, in this case, users should always be warned/encouraged to update as soon as the package is downloaded if used in production environment. However, the data package provides an easy way to test if the software meets the admin/user's requirements before he introduces the changes required in the environment [1] to support the software use in the long run. Regards Javier [1] Typically direct connection to the Internet or proxy reconfiguration. This is true in many organisational's internal network environments in which direct Internet access can not be taken for granted. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
* Javier Fernandez-Sanguino: > This really sounds like there is a "use case" for data-only > "packages" that: Is clamav-data really data-only? Other AV software ships some sort of code even in signature updates (as opposed to engine updates). > - do not include maintainer scripts (dpkg refuses to run them) or are > only allowed a set of limited tasks (run in a restricted shell or with > reduced privileges) > > - are only allowed to write in a specific place on disk (such as > /var/lib/) > > Wouldn't that reduce the problems surrounding clamav-data and other > frequently-updated data packages? It would mean that APT and dpkg have to deal with untrusted data in many more places. Not a good idea, IMHO. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic ITP closing.
Sandro Tosi wrote: [...] > > I'm personally happy that this script stops: ITP without work should > be retitled to RFP (since this way we don't loose the history of the > bugs if someone will step in) instead of closing it. > FWIW I have a script that I usually run to do WNPP bugs maintenance that could easily be extended to do that. Code can be found at: http://git.debian.org/?p=users/atomo64-guest/misc-devscripts.git;a=blob_plain;f=wnpp-maintenance.pl;hb=HEAD By the way, people helping to process the issues reported by the script are more than welcome. Adding a "@daily path/to/wnpp-maintenance.pl -e 2" cronjob would be a good way to get started (the output is an almost-ready email to cont...@bugs.d.o). Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The 'git' Debian package in squeeze
> > Well, except _not_ to abet the hostile takeover of a > > project name that has been around since ... I don't know, > > but the Debian package goes back to 1997. [Jon Dowland] > In what way is it hostile? It is hostile in the sense that nobody in Linus-git went to GNU-git to ask permission before using the same name for a whole different project. I could be wrong, maybe somebody did get permission. To be clear, I'm not accusing Debian of a hostile takeover, I'm accusing upstream of a hostile takeover. I'm accusing Debian of abetting it. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
zendframework package with or without bin package
Hi folks, i have created the package zendframework and zendframework-bin. The package zendframework contains the php libraries. The bin package contains two scripts with that you can create a mvc environment with the zendframework. This is only important for developers. So my question is, if i should also add the binary files to the zendframework package or if i should leave them separate? I also want to rename the package to libphp-zendframework. regards, Frank -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
By the way,.. a similar problem is also present in many other packages. Let me just name a few concrete examples so that you get a feeling on what I mean. 1) debootstrap/cdebootstrap IIRC, only cdeboostrap requires a keyring per default (or did it always use debian-archive-keyring?) Anyway,... while deboostrap supports verifying signatures and specifying a keyring,.. it doesn't to so per default. Neither does it fail if just nothing is specified (it should only work with verification, if some special parameter e.g. --dont-verify-sigs is given). I've filed a bug for this some time ago,... (and unfortunately a 2nd one recently) but it does not seem that upstream is willing to change this behaviour. 2) pbuilder and piuparts (and probably the debian buildd's, too) create chroots to build the packages, and I think they're using one of the aboves for this. Per default they're not configured to use them (well at least debootstrap) with signatures. => Building packages may lead to installation and execution of malicious packages. I've filed bugs for at least pbuilder and piuparts. 3) aptitude Well I'm not sure here as I haven't had the time to read the code. For some actions (install/upgrade/dist-upgrade) it uses secure-apt as it simply uses apt-get (IIRC). But what about actions not provided by apt-get, like aptitude download . So far I was not able to find out whether this uses secure apt or not. 4) apt-file (which I like very much) The Contents files are not yet signed AFAIK,.. and thus it cannot do any verification. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Anton Mitterer schrieb: > By the way,.. a similar problem is also present in many other packages. > Let me just name a few concrete examples so that you get a feeling on > what I mean. > > > > 1) debootstrap/cdebootstrap > IIRC, only cdeboostrap requires a keyring per default (or did it always > use debian-archive-keyring?) > Anyway,... while deboostrap supports verifying signatures and specifying > a keyring,.. it doesn't to so per default. > Neither does it fail if just nothing is specified (it should only work > with verification, if some special parameter e.g. --dont-verify-sigs is > given). > I've filed a bug for this some time ago,... (and unfortunately a 2nd one > recently) but it does not seem that upstream is willing to change this > behaviour. > > > 2) pbuilder and piuparts (and probably the debian buildd's, too) create > chroots to build the packages, and I think they're using one of the > aboves for this. > Per default they're not configured to use them (well at least > debootstrap) with signatures. > => Building packages may lead to installation and execution of malicious > packages. > > I've filed bugs for at least pbuilder and piuparts. > > > 3) aptitude > Well I'm not sure here as I haven't had the time to read the code. > For some actions (install/upgrade/dist-upgrade) it uses secure-apt as it > simply uses apt-get (IIRC). > > But what about actions not provided by apt-get, like aptitude download > . > So far I was not able to find out whether this uses secure apt or not. > > > 4) apt-file (which I like very much) > The Contents files are not yet signed AFAIK,.. and thus it cannot do any > verification. There are so many scenarios where we are not able to verify any signatures (upstream does not provide any kind of verification) or where it is non-sens. If we are so pedantic about this topic, we should also ask ourself, if packages like wget, curl, ncftp, ftp etc fullfil the security requirements. We can not secure *everything*, but the most important parts, which Debian itself controls. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkq5JD0ACgkQ2XA5inpabMfJYQCfba6GxGaOkzct0yN9iRvU/f6j 4nIAnAtayYfmdpYWgF9EZX/zE2J+8fHf =35fe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
On Tue, 2009-09-22 at 21:23 +0200, Patrick Matthäi wrote: > There are so many scenarios where we are not able to verify any > signatures (upstream does not provide any kind of verification) or where > it is non-sens. > > If we are so pedantic about this topic, we should also ask ourself, if > packages like wget, curl, ncftp, ftp etc fullfil the security requirements. > > We can not secure *everything*, but the most important parts, which > Debian itself controls. Of course not,.. but we can try to close as many "holes" as possible,.. especially when it's fairly easy to close them. Regarding the pubilder/boostrap/similar stuff,.. I'd actually say that it's quite critical if this is non secured. I must admit, that I don't know where the debian build severs get their packages for the build-envs from, but I assume also from some other ftp server?! If so,.. and if Mr. Evil sits in the middle of that line (and if no verification is done),.. he can do basically everything (and it will most likely hit ALL users of Debian (that install that built packages). And IMHO the same is true for anybody who does local builds or bootstrapping using one of the above tools (if it does not do verification). In all doing respect, being pedantic with security isn't a flaw, IMHO. Of course there are borders where the effort gets so high, that it isn't worth it, but still, one should always try to improve security as much as possible. :-) Best wishes, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: zendframework package with or without bin package
Frank Habermann wrote: > Hi folks, > > i have created the package zendframework and zendframework-bin. The > package zendframework contains the php libraries. The bin package contains > two scripts with that you can create a mvc environment with the > zendframework. This is only important for developers. > > So my question is, if i should also add the binary files to the > zendframework package or if i should leave them separate? The general answer is whether it has any benefit or not (size could be an example). > > I also want to rename the package to libphp-zendframework. > biased answer: ugh, why? That reminds me some of the libfoo-bar-moo-invent-something-else-here packages we have in the archive. P.S. -mentors would have been a more appropriate list for this question. Regards, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: zendframework package with or without bin package
On Sep 23, 2009, at 1:22, Raphael Geissert wrote: Frank Habermann wrote: I also want to rename the package to libphp-zendframework. biased answer: ugh, why? That reminds me some of the libfoo-bar-moo-invent-something-else-here packages we have in the archive. One possible answer to "why?" is that libfoo-bar-baz allows users easy access to a debian package that directly corresponds to the upstream software. In the case of a perl package on CPAN it would be called Test::File. In debian it would be called libtest-file-perl since the perl module is a library, renamed test-file in accordance with debian policy and - perl added to denote which programming language the package is written in. This allows one to have libtest-file, libtest-file-ruby, etc, without too many namespace collisions. Since a vast majority of debian perl packages are named this way, users know what to look for on a debian system simply by the upstream name. Jeremiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
QUICK guide to movies by topic @ informexp.com (about 100 topics!)
http://www.informexp.com/Flix.htm http://www.informexp.com/
Re: opposition against clamav-data in debian volatile
Le Tue, Sep 22, 2009 at 02:13:38PM +0200, Javier Fernandez-Sanguino a écrit : > > This really sounds like there is a "use case" for data-only "packages" that: > > - do not include maintainer scripts (dpkg refuses to run them) or are > only allowed a set of limited tasks (run in a restricted shell or with > reduced privileges) > > - are only allowed to write in a specific place on disk (such as > /var/lib/) > > Wouldn't that reduce the problems surrounding clamav-data and other > frequently-updated data packages? > > Maybe that's something that could be taken on board by dpkg > maintainers? Hi Javier, it is an interesting idea to define a set of criteria that data package must follow, but I think it will be much easier for everybody to have this enforced by a policy rather than by tools. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Darren Scott has invited you to join Friendster
You're invited to join Darren Scott's network of friends. By joining Friendster, you can reconnect with old friends, meet new friends, start a blog, build a custom profile, keep track of birthdays, and so much more! You can even stay in touch if you move away, switch email addresses, or lose your mobile phone. Click below to join Darren's network. http://www.friendster.com/join.php?inviteref=114521418&invite=rLFdb9Wx9qnLp0gZ0XK-61o7vpHJ5Bw46Vr9Vv5Wyh4*&lang=en-US * If you do not wish to receive notification emails from Friendster, please click below: http://www.friendster.com/blockemails.php?invite=ZGViaWFuLWRldmVsQGxpc3RzLmRlYmlhbi5vcmc*
Re: zendframework package with or without bin package
On Tue, Sep 22, 2009 at 06:22:20PM -0500, Raphael Geissert wrote: > > > > I also want to rename the package to libphp-zendframework. > > > > biased answer: ugh, why? > That reminds me some of the libfoo-bar-moo-invent-something-else-here > packages we have in the archive. the php policy draft recommends something along these lines as well, though in practice i think there are more php[N]-foo than there are libfoo-php[N]. while originally the intent was to seperate extensions and php libraries into two seperate naming conventions, it doesn't seem like this is realistic or worth the effort to try and police. sean signature.asc Description: Digital signature
