Re: exim-using packages - are you relying on -C or -D options?
Ian Jackson wrote:
> Andreas Metzler writes ("Re: exim-using packages - are you relying on -C or
> -D options?"):
>> The current status (GIT head) simply adds a file which contains a *list*
>> of trusted configuration files instead of a prefix.
> That's good enough for me. And it should be good enough for anyone
> else because you can have anything which needs to generate a config on
> the fly edit the list (via something like userv if it isn't already
> running as root).
> Thanks for taking the time to discuss and investigate this. I
> appreciate the attention to detail and particularly to compatibility :-).
Thank you for the feedback. The update seems to be more or less done
now.
http://www.bebt.de/blog/debian/archives/2010/12/21/T16_35_58/index.html
cu andreas
--
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/kbu8u7-86a@argenau.downhill.at.eu.org
Re: Bug#602246: ITP: brian -- simulator for spiking neural networks
oops -- sorry for the delay -- just found this comment and then what to do if we have not decided yet what particular humanoid will accomplish the mission? On Wed, 03 Nov 2010, Raphael Hertzog wrote: > > Package: wnpp > > Severity: wishlist > > Owner: NeuroDebian Team > Please use your real name even if you're doing some work as part of a > team... -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20101222151313.gc8...@onerussian.com
Re: Bug#602246: ITP: brian -- simulator for spiking neural networks
Hi, On Wed, 22 Dec 2010, Yaroslav Halchenko wrote: > oops -- sorry for the delay -- just found this comment > > and then what to do if we have not decided yet what particular humanoid > will accomplish the mission? It doesn't matter much. You can always change the submitter afterwards. If you have no volunteer to do the work, it could be argued that you should first file a RFP and change it into an ITP once you know who will do the work. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101222152403.gb18...@rivendell.home.ouaza.com
Bug#607815: ITP: libapp-rad-perl -- Perl module for rapid and easy creation of command line applications
Package: wnpp Owner: Salvatore Bonaccorso Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libapp-rad-perl Version : 1.04 Upstream Author : Breno G. de Oliveira * URL : http://search.cpan.org/dist/App-Rad/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module for rapid and easy creation of command line applications App::Rad aims to be a simple yet powerful framework for developing your command-line applications. It can easily transform your Perl one-liners into reusable subroutines than can be called directly by the user of your program. It also tries to provide a handy interface for your common command-line tasks. If you have a feature request to easen out your tasks even more, please drop me an email or a RT feature request. -- 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/1293031524.927074.8...@elende
securing/monitoring Debian devel environment
Dear Debian Comrades, I can take blame if I am the only one who is somewhat jeopardizing our project by relying solely on his own eyes, fingers, GIT, belief in a good will of upstream developers, and moreover trust in the security of the upstream developers systems and their repositories. But I guess, I am more of a typical Debian contributor, who develops Debian contributions on the same system where sensitive keys (SSH, GPG) are kept and even more -- ssh/gpg-agents are running from time to time. I do inspect upstream code, and I do check on good intentions of upstream developers; but I am not relying on some automated (thus objective) way to assure that my system does not get jeopardized while the package is being built (in my account or may be as root under pbuilder) or tested. If upstream code, for some reason, contained malicious code which would set up a backdoor or simply perform some malicious actions targeting Debian servers/uploads, it would be unfortunately possible for it to take advantage of my system having access to debian infrastructure (may be not right away, since keys would not be loaded atm and I do use passphrases; but at a later point after injection of the malicious script). The only way to completely prevent that would be to develop and build packages in a completely isolated (virtual machine) environment with good monitoring/reporting facilities if some abnormal actions (unwarranted access to the network, creation/editing/adding files outside of the build-tree) have happened. So, I wondered what available software solutions other Debian contributors might be already using to assure the security of their systems while working on the upstream code (building/packaging/running). (just to make clear, sanitising the environment by debuild is not enough) May be there is a lightweight utility which could be used for monitoring, e.g. it would report suspicious actions being taken from within a monitored environment? e.g., it would * sanitize environment variables * monitor open/socket/... syscalls and report abnormal activities (e.g. opening network connection, writing to a file outside of build-tree,/tmp/, etc) * provide a summary at the end on the invoked actions by the target command I guess a possible solution which would not only monitor but guarantee would be SELinux, but I am afraid it might be somewhat cumbersome to setup policies across the variety of packages I maintain. So I just wanted to monitor to start with. Any recommendations on existing solutions/setups would be really welcome ;) Yours truly, -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic signature.asc Description: Digital signature
Bug#607821: ITP: haskell-strptime -- Haskell binding for strptime with some extra features
Package: wnpp Severity: wishlist Owner: Eugene Kirpichov X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: haskell-strptime Version : 0.1.8 Upstream Author : Eugene Kirpichov * URL : http://hackage.haskell.org/package/strptime * License : New BSD License Programming Lang: Haskell, C Description : Haskell binding for strptime with some extra features A Haskell binding for strptime with some extra features - namely, %OS is for fractional seconds and %^[+-][N]s is for seconds since epoch - for example, %^-3s is milliseconds since epoch. -- 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/aanlktinw0kaxk5mcvfapsz9bt_r-m9+pmusjb8wsb...@mail.gmail.com
owner for ITP bugreports [Was: Bug#602246: ITP: brian -- simulator for spiking neural networks]
Ah, now I found where I screwed up: I have my personal email as the email address but with a Team name. I have used reportbug --realname="NeuroDebian Team" --email=t...@neuro.debian.net -b wnpp and because I did have REPORTBUGEMAIL env var set to my email, it took precedence over --email. Good to know... I will fix-up relevant ITPs to contain proper entry NeuroDebian Team Meanwhile discussion on a generic topic "owner for ITP -- team vs individual": On Wed, 22 Dec 2010, Raphael Hertzog wrote: > > and then what to do if we have not decided yet what particular humanoid > > will accomplish the mission? > It doesn't matter much. You can always change the submitter afterwards. nah, then we should do it upon every commit to the repository while multiple people working on the packaging... > If you have no volunteer to do the work, it could be argued that you > should first file a RFP and change it into an ITP once you know who will > do the work. yes, we do have volunteers (more than 1) to do the work -- it is us, the team. It might end up being one specific person, or multiple developers working on it at the same time... it depends, our primary goal is to get job done. Overall, what specific problem (if there is any) would be solved by requesting to specify some other than team name/address for the package which is going to be team maintained? imho none Meanwhile more arguments why I consider team contact appropriate (and even preferable at times) for the Owner of an ITP, in contrast to a single, possibly arbitrarily chosen, developer from the team: * Team contacts are our preferable entry for the "Maintainer" field in the packaged package Many benefits of having team in the maintainer apply to having team in the owner of ITP: more eyes, aggregated qa. page etc * We have no strict requirement for the submitters of ITPs being a DD. it could be owned by an arbitrary (possibly fictional) person with arbitrarily contact email (possibly fake); so NeuroDebian Team could be treated as a single humanoid with an email t...@neuro.debian.net ;) or we could come up with a more specific one A.Humanoid to be forwarded to team@ ;) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20101222165225.ge8...@onerussian.com
Re: Full install/removal/upgrade test results available
Le mardi 21 décembre 2010 à 20:59 +0100, Mike Hommey a écrit : > Adding update-python-modules -p in python-xpcom postinst could make > things slightly better, but that would still leave xulrunner-1.9.1's > postinst complaining if it's run before python-xpcom's. > > What if xulrunner-1.9.1's postinst would do nothing for configure ? > would the trigger still kick in when one installs xulrunner-1.9.1 only? You could use dpkg-trigger to force the trigger to be run after xulrunner-1.9.1 being installed. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: securing/monitoring Debian devel environment
Yaroslav Halchenko writes: > script). The only way to completely prevent that would be to develop and > build packages in a completely isolated (virtual machine) environment Interesting ideas but don't you also need to run the produced binaries in isolation? If we assume a malicious upstream they can surely make the build innocent but then have the produced binaries launch sudojump [1] in the background and have it root your machine the next time you use sudo. Since you mentioned ssh-agent: They can also use ssh-jack [2] to run commands on all machines where you have open ssh connections, they don't need to wait for you to start a new ssh connection. [1] http://seclists.org/bugtraq/2007/Jun/16 [2] http://www.storm.net.nz/projects/7 -- 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/84sjxp32hx@sauna.l.org
Re: securing/monitoring Debian devel environment
On Wed, 22 Dec 2010, Timo Juhani Lindfors wrote: > > script). The only way to completely prevent that would be to develop and > > build packages in a completely isolated (virtual machine) environment > Interesting ideas but don't you also need to run the produced binaries > in isolation? exactly -- that is what I meant by 'built (...) and *tested*' ;) > If we assume a malicious upstream they can surely make > the build innocent but then have the produced binaries launch sudojump > >...< sure -- many bad things can happen in various reincarnations of the malicious desires of upstreams or just those who hijack their projects/distribution ;-) the question remains: how could we set our development environments so they remain convenient to use and would help us to detect such misdemeanours so we keep Debian infrastructure secure. Pure isolation of build/test environment would help, but without easy monitoring, it would just postpone detection of malicious attempts so they would activate (again) during builds across our buildd farm, or running on the boxes of those who installed the packages (often DDs as well, since we do eat our own ...) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/2010121651.gf8...@onerussian.com
Re: owner for ITP bugreports [Was: Bug#602246: ITP: brian -- simulator for spiking neural networks]
On Wed, 22 Dec 2010, Yaroslav Halchenko wrote: > > It doesn't matter much. You can always change the submitter afterwards. > > nah, then we should do it upon every commit to the repository while > multiple people working on the packaging... Of course not, my request is that the submitter is a human-being not that it matches the last-person having worked on the packaging. > Overall, what specific problem (if there is any) would be solved by > requesting to specify some other than team name/address for the package which > is going to be team maintained? imho none When I reply to some ITP with advice, I like to know who wrote the ITP. > Meanwhile more arguments why I consider team contact appropriate (and > even preferable at times) for the Owner of an ITP, in contrast to a single, > possibly arbitrarily chosen, developer from the team: > > * Team contacts are our preferable entry for the "Maintainer" field > in the packaged package That's fine. You can put the team as the "owner" of the bug and you'll get the BTS traffic to the team email. But if you really use a "team identity" to submit ITP, I would ask you to at least sign your message (i.e. put your own human name at the end). Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101223071312.gd21...@rivendell.home.ouaza.com
