opposition against clamav-data in debian volatile
On Tue, Sep 22, 2009 at 14:21, Florian Weimer wrote: > * 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). > Yes, the signatures contain only signatures, which are hexadecimal patterns with wildcards, hashes, and so on. See http://www.clamav.net/doc/latest/signatures.pdf For ClamAV 0.96 we have planned support for bytecode signatures, see http://www.clamav.net/about/roadmap. This is not directly executable code, but bytecode that is executed by an interpreter/JIT, and doesn't have access to the system in any way, it only has access to a restricted set of ClamAV APIs. Regarding freshclam, there are 2 ways to setup a local mirror, described here, see the question "I’m running ClamAV on a lot of clients on my local network. Can I serve the cvd files from a local server so that each client doesn’t have to download them from your servers?" http://www.clamav.net/support/faq/faq-cvd/ Best regards, --Edwin -- 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
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
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: 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
* 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
Re: opposition against clamav-data in debian volatile
On Mon, 21 Sep 2009, James Vega wrote: > On Mon, Sep 21, 2009 at 11:49 AM, Henrique de Moraes Holschuh > wrote: > > On Mon, 21 Sep 2009, Marc Haber wrote: > >> And people know that the package is built automatically. All users I > >> know especially opted in to using the package instead of freshclam for > >> some-or-other reason. > > > > WHERE is that information published? > > > > I don't see it in the package description, and I don't see it in > > volatile.d.o either. It is not even in the for-developers page. > > >From the description of the volatile package: > > This package contains data files for clamav and was automatically > generated by clamav-getfiles from the identically named package. > ... > Please note that this package was built automatically without human > supervision and was only automatically checked before upload. Use at > your own risk. Thank you. I misused apt-cache and got the package description from a box that didn't have volatile.d.o in the sources list. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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
On Mon, Sep 21, 2009 at 11:49 AM, Henrique de Moraes Holschuh wrote: > On Mon, 21 Sep 2009, Marc Haber wrote: >> And people know that the package is built automatically. All users I >> know especially opted in to using the package instead of freshclam for >> some-or-other reason. > > WHERE is that information published? > > I don't see it in the package description, and I don't see it in > volatile.d.o either. It is not even in the for-developers page. >From the description of the volatile package: This package contains data files for clamav and was automatically generated by clamav-getfiles from the identically named package. ... Please note that this package was built automatically without human supervision and was only automatically checked before upload. Use at your own risk. -- 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
On Mon, 21 Sep 2009, Marc Haber wrote: > And people know that the package is built automatically. All users I > know especially opted in to using the package instead of freshclam for > some-or-other reason. WHERE is that information published? I don't see it in the package description, and I don't see it in volatile.d.o either. It is not even in the for-developers page. Was it somehow lost or misplaced in the web pages? Or is it just inside the package, or in a blog somewhere, or in a mailing-list post somewhere? Those would not give that information anywhere near the necessary exposal to people who are considering installing the package for the first time. > > If someone has network access to fetch > >clamav-data, he also has network access to fetch the signatures, so he could > >run the "create-clamav-data" utility instead... > > This assumption is wrong. I am honestly curious about this one. Look, I don't have anything against gatekeeper procedures being put in place to keep the current way clamav-data is built, although I *still* don't understand why clamav-data is necessary, and therefore I don't understand either why it would warrant so much effort and complexity [to do it right]. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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
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. 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? Kind regards, Philipp Kern -- 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
* 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? ClamAV, like about every other antivirus scanner, is used to fight rapidly moving targets. It relies on current -data files to provide any kind of useful service to its users. "Malware vs. Anti-Malware: (How) Can We Still Survive?"[1] may give you a bit of an idea how fast the targets are moving. 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. If it's really necessary to generate the signature with manual intervention, we are going to need a 24/7 commitment by a group of people to a response time of a few hours or less for every update. > 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. There are only a few places from where malicious code could be executed on behalf of the package creator: The maintainer scripts (preinst, postinst, prerm, postrm, config) and any executables that may be part of the package. The maintainer scripts can be checked and stay constant across new version, and the list of files shipped in the clamav-data package is fixed. This stuff can easily be checked automatically between upload and accepting the package into the archive. I know that whenever I claim that something should be easy, people tend to answer "show me the code", so there: If whoever in charge states that my idea is acceptable, I'll be happy to implement limited checking of pacakge contents in the archive software. -Hilko [1] http://av-test.org/down/papers/2008-02_vb_comment.pdf -- 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
On Mon, 21 Sep 2009 07:52:48 +0200, Luk Claes wrote: >The time complaining in this thread could probably better spent by >talking to ftpmas...@d.o and implementing a solution btw. Why do I need to actively talk to ftpmaster when it's them wanting to implement changes to a setup which has been implemented in close cooperation with their precedessors and which has been working for years? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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
Marc Haber wrote: > On Sun, 20 Sep 2009 18:28:30 -0300, Henrique de Moraes Holschuh > wrote: >> On Sun, 20 Sep 2009, Marc Haber wrote: > No. The process runs on a virtual machine on a host privately owned > and operated by the previous ftpmaster of Debian volatile, and was > carefully designed in close cooperation with the former Debian > volatile team. It is a real shame that the new Debian volatile team > decided to put up more hoops to jump through after clamav-data was one > of the first packages to be included with Debian volatile. Please stop spreading FUD. The extended team decided to try to integrated with the main archive. The ftpmasters of the main archive have more strict rules about how packages can be accepted, though it will still be the volatile team that decides which packages could go in. The time complaining in this thread could probably better spent by talking to ftpmas...@d.o and implementing a solution btw. Cheers Luk -- 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
On Sun, 20 Sep 2009 18:28:30 -0300, Henrique de Moraes Holschuh wrote: >On Sun, 20 Sep 2009, Marc Haber wrote: >> As long as you do not expect me to manually sign every single upload, > >Why not? Because nobody pays me to spend an hour a day to sign packages. We had three full cycles since I went to bed seven hours ago. > It is a package, it has root access anywhere it is being installed >or removed. And people know that the package is built automatically. All users I know especially opted in to using the package instead of freshclam for some-or-other reason. >As you said, you'd have >to jump through a lot of loops to do special validation of that specific >package before installing it. ... which can be fully automated. >If it would still address whatever problem space clamav-data wants to fix, >maybe it would be easier if you created a package-generator package (that >creates a fresh clamav-data package for the user when, e.g. a >create-clamav-data command is run). See clamav-getfiles. The script which build the package is - of course - packaged. I guess that you didn't even look at whet you're trying to kill. > If someone has network access to fetch >clamav-data, he also has network access to fetch the signatures, so he could >run the "create-clamav-data" utility instead... This assumption is wrong. >> It would be massively easier if I knew what are the real issues > >What jumps immediately to mind is that someone could get a hold of that key, >and upload a trojan or bomb that will run as root on anyone that installs >(or removes, whatever) the package. Not if the key would be limited to clamav-data only and if the archive would verify whether the new package only differs to some "golden" package in the actual signatures. >> That being said, it looks like volatile's policies are going to change >> BIG TIME when it gets integrated into the main archive, and frankly, >> as a volatile user, I'd rather see volatile stay separate than seeing >> some of its previous principles dumped. > >Do you have a very secure setup involving two boxes, one of which is fully >offline and talks to the first one using a safe, restricted, application >layer link to get the clamav data, and upload the finished package back to >the first box? No. The process runs on a virtual machine on a host privately owned and operated by the previous ftpmaster of Debian volatile, and was carefully designed in close cooperation with the former Debian volatile team. It is a real shame that the new Debian volatile team decided to put up more hoops to jump through after clamav-data was one of the first packages to be included with Debian volatile. Oh well, some more motivation to work on Debian going down the drain. Well done. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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
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. If it would still address whatever problem space clamav-data wants to fix, maybe it would be easier if you created a package-generator package (that creates a fresh clamav-data package for the user when, e.g. a create-clamav-data command is run). If someone has network access to fetch clamav-data, he also has network access to fetch the signatures, so he could run the "create-clamav-data" utility instead... > It would be massively easier if I knew what are the real issues What jumps immediately to mind is that someone could get a hold of that key, and upload a trojan or bomb that will run as root on anyone that installs (or removes, whatever) the package. > That being said, it looks like volatile's policies are going to change > BIG TIME when it gets integrated into the main archive, and frankly, > as a volatile user, I'd rather see volatile stay separate than seeing > some of its previous principles dumped. Do you have a very secure setup involving two boxes, one of which is fully offline and talks to the first one using a safe, restricted, application layer link to get the clamav data, and upload the finished package back to the first box? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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
On Sun, 20 Sep 2009 17:10:45 +0200, Luk Claes wrote: >Hmm, nothing is black and white. The current way of uploading >clamav-data is suboptimal and ftpmasters don't want that to continue >when volatile is integrated in the main archive. Though that does not >mean there are no alternatives. Back then you did not seem interested in >any alternative way of doing it and rather discontinue the service >completely. Is this still true or should we start thinking of alternatives? As long as you do not expect me to manually sign every single upload, I'm fine with alternatives. Back when Andreas was in charge, he said that he'd prefer the packages to be unsigned instead of being automatically signed with a passphaseless key. I am fine with reducing the upload frequency (and would, in that case, continue to provide more frequently built packages on people.d.o), but I am not fine with regular manual work being required. I am also fine with more paranoia before the upload, for example, to have kind of a "master" package on a trusted system which would be debdiffed against a newly built package to catch differences in the file list. It would be massively easier if I knew what are the real issues instead of sending someone saying in IRC "ftpmaster doesn't want clamav-data any more, please ready yourself to see your work going down the drain" but doesn't know any more. That being said, it looks like volatile's policies are going to change BIG TIME when it gets integrated into the main archive, and frankly, as a volatile user, I'd rather see volatile stay separate than seeing some of its previous principles dumped. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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
Marc Haber wrote: > On Sat, 19 Sep 2009 15:52:17 + (UTC), Philipp Kern > wrote: >> On 2009-09-19, Marc Haber wrote: >>> On Fri, 18 Sep 2009 15:56:07 + (UTC), Philipp Kern >>> wrote: On 2009-09-18, Tom Feiner wrote: > Looks like this method works well for clamav-data and other similar > packages > which needs to update databases frequently on stable/oldstable. clamav-data is scheduled for deletion as soon as volatile moves onto ftp-master, so that's no precedent. (I.e. there is opposition against daily builds entering the archive without real developers signing them.) >>> Why does the person responsible for these uploads not know about this >>> opposition? Why was the person doing the significant work not informed >>> about the fact that every single minute put into the package is wasted >>> anyway? >> If I recall the channel discussion correctly you were present and aware of >> the discontinuation. Maybe I recall it incorretly, though. > > Das muss ich verdrängt haben. I still get absolutely furious about > this "decision" when I think about it, so I'd better not think about > it. > > Thanks for the reminder. I'm going to kill off clamav-data the second > the build process breaks for the next time. It's really a shame to see > weeks of work going down the drain due to political restrictions. Hmm, nothing is black and white. The current way of uploading clamav-data is suboptimal and ftpmasters don't want that to continue when volatile is integrated in the main archive. Though that does not mean there are no alternatives. Back then you did not seem interested in any alternative way of doing it and rather discontinue the service completely. Is this still true or should we start thinking of alternatives? Cheers Luk -- 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 (was: Packages that download/install unsecured files)
On Sat, 19 Sep 2009 15:52:17 + (UTC), Philipp Kern wrote: >On 2009-09-19, Marc Haber wrote: >> On Fri, 18 Sep 2009 15:56:07 + (UTC), Philipp Kern >> wrote: >>>On 2009-09-18, Tom Feiner wrote: Looks like this method works well for clamav-data and other similar packages which needs to update databases frequently on stable/oldstable. >>>clamav-data is scheduled for deletion as soon as volatile moves onto >>>ftp-master, so that's no precedent. (I.e. there is opposition against >>>daily builds entering the archive without real developers signing them.) >> Why does the person responsible for these uploads not know about this >> opposition? Why was the person doing the significant work not informed >> about the fact that every single minute put into the package is wasted >> anyway? > >If I recall the channel discussion correctly you were present and aware of >the discontinuation. Maybe I recall it incorretly, though. Das muss ich verdrängt haben. I still get absolutely furious about this "decision" when I think about it, so I'd better not think about it. Thanks for the reminder. I'm going to kill off clamav-data the second the build process breaks for the next time. It's really a shame to see weeks of work going down the drain due to political restrictions. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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 (was: Packages that download/install unsecured files)
On 2009-09-19, Marc Haber wrote: > On Fri, 18 Sep 2009 15:56:07 + (UTC), Philipp Kern > wrote: >>On 2009-09-18, Tom Feiner wrote: >>> Looks like this method works well for clamav-data and other similar packages >>> which needs to update databases frequently on stable/oldstable. >>clamav-data is scheduled for deletion as soon as volatile moves onto >>ftp-master, so that's no precedent. (I.e. there is opposition against >>daily builds entering the archive without real developers signing them.) > Why does the person responsible for these uploads not know about this > opposition? Why was the person doing the significant work not informed > about the fact that every single minute put into the package is wasted > anyway? If I recall the channel discussion correctly you were present and aware of the discontinuation. Maybe I recall it incorretly, though. Please see also: http://lists.debian.org/debian-volatile-announce/2009/msg3.html However progress in the move is currently non-existant. It looked better at some point back then. Kind regards, Philipp Kern -- 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 (was: Packages that download/install unsecured files)
On Sat, 19 Sep 2009, Marc Haber wrote: > Why does the person responsible for these uploads not know about this > opposition? Why was the person doing the significant work not informed > about the fact that every single minute put into the package is wasted > anyway? Because nothing happened yet and nothing is going to happen this week. or next week. or the week after that. And I suppose that once something actually does happen we all can come up with a solution that doesn't involve accepting *unsigned* packages into the archive. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
opposition against clamav-data in debian volatile (was: Packages that download/install unsecured files)
On Fri, 18 Sep 2009 15:56:07 + (UTC), Philipp Kern wrote: >On 2009-09-18, Tom Feiner wrote: >> Looks like this method works well for clamav-data and other similar packages >> which needs to update databases frequently on stable/oldstable. > >clamav-data is scheduled for deletion as soon as volatile moves onto >ftp-master, so that's no precedent. (I.e. there is opposition against >daily builds entering the archive without real developers signing them.) Why does the person responsible for these uploads not know about this opposition? Why was the person doing the significant work not informed about the fact that every single minute put into the package is wasted anyway? I wasn't informed once about the changes that were applied to the volatile mechanisms in the last year. All interruptions in the clamav-data delivery were caused by unannounced changes. Does the project want me to stop providing clamav-data starting tomorrow? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
