Bug#613788: ITP: dropbox -- secure backup, sync and sharing util
Package: wnpp Severity: wishlist Owner: Vincent Cheng * Package name: dropbox Version : 1.0.20-1 Upstream Author : Dropbox, Inc. * URL : http://www.dropbox.com * License : Proprietary Section : non-free/net Description : secure backup, sync and sharing util Dropbox is a Web-based file hosting service operated by Dropbox, Inc. which uses cloud computing to enable users to store and share files and folders with others across the Internet using file synchronization. This package only contains the Dropbox daemon; it does not contain the Nautilus plugin for Dropbox. -- 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/20110217083526.29472.58814.reportbug@vincent-laptop
Re: Bug#613788: ITP: dropbox -- secure backup, sync and sharing util
On 2011-02-17, Vincent Cheng wrote: > * Package name: dropbox > Version : 1.0.20-1 > Upstream Author : Dropbox, Inc. > * URL : http://www.dropbox.com > * License : Proprietary > Section : non-free/net > Description : secure backup, sync and sharing util You should consider http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610300 first. 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 Archive: http://lists.debian.org/slrnilpo1r.84b.tr...@kelgar.0x539.de
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)
17.02.2011 07:07, Robert Edmonds wrote: > 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) Yes, both of these are really useful. I have this done long ago locally on some notebook - trivially doable based on bind9 scripts. I just can't find it right now. But indeed, this (#567879) needs unbound-control working, or else it's impossible to change unbound config at runtime. This is not a problem IMHO, to enable unbound-control by default in new install. Check for 'control-enable: no' in unbound.conf (ie, if it is explicitly disabled) before enabling it, and log a warning if updating list of forwarders failed in dhcp script (if updating is enabled in /etc/default/unbound) > * enabling DNSSEC validation by default. (#594911) This is very useful, but questionable, since it makes unbound to require writable files (now it does not write anything except of the pid file). This in turn makes it difficult to chroot it properly - it can only be chrooted into /etc, and I'd rather keep /etc read-only during normal operations. However, debian initscript does not have provisions for chrooting it. > 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. What do you mean here? > * 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. That's all good points. Maybe a debconf question (whenever to enable dnssec and to fetch the root keys etc) is in order. Thanks! /mjt -- 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/4d5cf693.5090...@msgid.tls.msk.ru
Bug#613806: ITP: mplayer2 -- next generation movie player for Unix-like systems
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: mplayer2 Version : 2.0beta1 Upstream Author : Uoti Urpala * URL : http://www.mplayer2.org/ * License : GPL Programming Lang: C Description : next generation movie player for Unix-like systems MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files, supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. It can also play VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies. Another big feature of MPlayer is the wide range of supported output drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, DirectFB, but also SDL (plus all its drivers) and some low level card-specific drivers (for Matrox, 3Dfx and Radeon, Mach64 and Permedia3). Most of them support software or hardware scaling, therefore allowing fullscreen display. MPlayer is also able to use some hardware MPEG decoder boards, such as the DVB and DXR3/Hollywood+. The text above is copied from the existing mplayer package. It is basically a well-known and quite popular fork of mplayer. TBH, I'm a bit unsure what to do with it. From the first look, it seems that mplayer2 is better suited for being included in a distro release, but not (yet) in its current form. Currently, it includes a copy of ffmpeg-mt, a well-known fork of the ffmpeg package, which features multithreaded h264 decoding and actually is already in debian as part of the chromium-browser package. While ffmpeg-mt is currently being integrated/merged into ffmpeg upstream, mplayer2's future is not that certain. Having this in mind, I intend to maintain the package under the pkg-multimedia umbrella. mplayer2 shoudl go to experimental for now, including ffmpeg-mt. Help and ideas with that is more than welcome! -- 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/20110217115115.5101.47056.reportbug@debian
Default Homedir Permissions
Hi, Default homedir permissions are 755. World-readable (and listable). Common (security) sense says that permissions that are not required should not be granted. For example, accounts mysql and www-data should not have access to my documents. Some time ago I filed a bug related to this: 398793 The maintainer didn't agree and asked me to bring this up on this list. What do you think? The (only) disadvantage is that ~/public_html requires you too grant permission manually. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398793 -- Olaf -- 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/aanlktin3n3j_dxds0zvrhhhfgo9mvvjrpg+yywdvy...@mail.gmail.com
Re: Default Homedir Permissions
* Olaf van der Spek [2011-02-17 13:51]: > Default homedir permissions are 755. World-readable (and listable). > Common (security) sense says that permissions that are not required > should not be granted. For example, accounts mysql and www-data should > not have access to my documents. > > Some time ago I filed a bug related to this: 398793 > The maintainer didn't agree and asked me to bring this up on this > list. What do you think? > The (only) disadvantage is that ~/public_html requires you too grant > permission manually. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398793 IIRC you are asked during installation if you want world readable home directories or not. Kind regards, Martin -- 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/20110217125231.gt12...@anguilla.debian.or.at
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 1:52 PM, Martin Wuertele wrote: > IIRC you are asked during installation if you want world readable home > directories or not. No you're not. Unless (I assume) you do an expert install. Even then, non-world-readble means 751, not 750. The default should still change. -- Olaf -- 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/AANLkTi=66vthmh2--ape7jqq4nwv_jdf1rhl17amk...@mail.gmail.com
Re: Default Homedir Permissions
* Olaf van der Spek [2011-02-17 13:56]: > On Thu, Feb 17, 2011 at 1:52 PM, Martin Wuertele wrote: > > IIRC you are asked during installation if you want world readable home > > directories or not. > > No you're not. Unless (I assume) you do an expert install. Even then, > non-world-readble means 751, not 750. The default should still change. You are right about the expert install (I can't remember when I last did a non-expert install). 751 togeather with a default umask of 027 would work, however several programs don't work flawless with non 022 or 002 umaks (eg #531885). Kind regards, Martin p.s. no need to CC me as I'm subscribed -- 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/20110217132710.gu12...@anguilla.debian.or.at
SEVEN KINGS en Tournée 2011
SEVEN KINGS Officiel Sons of the Gipsy Kings Les fils des Gipsy Kings vous feront voyager dans la musique Gitane d'hier et d'aujourd'hui SEVEN KINGS interprètent les plus beaux titres du répertoire des GIPSY KINGS, leurs pères, et de nouvelles compositions qui vous attendent dans cette tournée 2011 C'est ainsi qu'ils suivent le chemin de la grande lignée des REYES. Programmez vos dates : http://www.od-prod.com/e-mailing/contact.php?camp=sevenkings&lien=Contact&email=oliv...@od-prod.com Tél : 00 33 4 66 84 59 58 www.seven-kings.com Seven kings 7 Rue Félibre Roumieux 30900 NIMES
Re: Default Homedir Permissions
Olaf van der Spek writes ("Default Homedir Permissions"):
> Default homedir permissions are 755. World-readable (and listable).
> Common (security) sense says that permissions that are not required
> should not be granted. For example, accounts mysql and www-data should
> not have access to my documents.
I disagree with this conclusion, because I disagree with the
underlying implication that the general readability of files is not
needed.
Most installed systems have a smallish number of users who know each
other reasonably well and would like to be able to share files. It
does not make sense to put strong privacy barriers in between those
users. Sensitive data like email and browser histories are already
made non-world-readable.
So the default is correct.
Perhaps it might be reasonable to try to find a way for accounts like
msql and www-data not to be able to access home directories (add
"daemon" to their supplementary group list and set the permissions of
/home 0705 to root.daemon, perhaps), but is this really worthwhile ?
If it is, the right thing to do is to go away and think about exactly
how to do it, not to file a bug asking for the default home directory
permissions to be changed.
Ian.
--
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/19805.9786.37599.609...@chiark.greenend.org.uk
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 2:44 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Default Homedir Permissions"):
>> Default homedir permissions are 755. World-readable (and listable).
>> Common (security) sense says that permissions that are not required
>> should not be granted. For example, accounts mysql and www-data should
>> not have access to my documents.
>
> I disagree with this conclusion, because I disagree with the
> underlying implication that the general readability of files is not
> needed.
> Most installed systems have a smallish number of users who know each
> other reasonably well and would like to be able to share files. It
What are those assumptions based on?
And how do you go from "want to share some files" to "default to share
all files"?
> does not make sense to put strong privacy barriers in between those
> users. Sensitive data like email and browser histories are already
> made non-world-readable.
chmod 755 ~ is not a hard way to remove the barrier.
> So the default is correct.
>
> Perhaps it might be reasonable to try to find a way for accounts like
> msql and www-data not to be able to access home directories (add
> "daemon" to their supplementary group list and set the permissions of
> /home 0705 to root.daemon, perhaps), but is this really worthwhile ?
That would be another violation of general security principles (access
control based on exlcusion instead of inclusion);
> If it is, the right thing to do is to go away and think about exactly
> how to do it, not to file a bug asking for the default home directory
> permissions to be changed.
The bug wasn't about that, although it was related.
--
Olaf
--
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/AANLkTim3=P6Ed-=z+vnpagvfhm-fh+4gn32pbso3m...@mail.gmail.com
Re: Bug#613788: ITP: dropbox -- secure backup, sync and sharing util
On Thu, Feb 17, 2011 at 12:35:26AM -0800, Vincent Cheng wrote: > * Package name: dropbox > Version : 1.0.20-1 > Upstream Author : Dropbox, Inc. > * URL : http://www.dropbox.com > * License : Proprietary > Section : non-free/net > Description : secure backup, sync and sharing util It looks like you're still missing the source for librsync.so.1 in your packages. Also, I *strongly* recommend that you not include binary-only shared libraries that are already available in Debian. The security team will not be very happy with you. As an example, your package ships libz.so.1, which has been the target of a DSA previously. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Default Homedir Permissions
Olaf van der Spek writes ("Re: Default Homedir Permissions"):
> chmod 755 ~ is not a hard way to remove the barrier.
We are arguing about defaults, so this is not a relevant answer.
> What are those assumptions based on?
I could ask you the same question. We are arguing in a vacuum.
I don't think we should make a change, but people who want defaults
changed always make more noise than people who are happy with the way
they are. I just wanted to make it clear that this change would not
be universally welcomed.
I don't think there is anything else useful to be said in this
subthread.
Ian.
--
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/19805.13004.7522.663...@chiark.greenend.org.uk
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 03:31:18PM +0100, Olaf van der Spek wrote:
> On Thu, Feb 17, 2011 at 2:44 PM, Ian Jackson
> wrote:
> > Olaf van der Spek writes ("Default Homedir Permissions"):
> >> Default homedir permissions are 755. World-readable (and listable).
> >> Common (security) sense says that permissions that are not required
> >> should not be granted. For example, accounts mysql and www-data should
> >> not have access to my documents.
> >
> > I disagree with this conclusion, because I disagree with the
> > underlying implication that the general readability of files is not
> > needed.
>
> > Most installed systems have a smallish number of users who know each
> > other reasonably well and would like to be able to share files. It
…
> > So the default is correct.
> >
> > Perhaps it might be reasonable to try to find a way for accounts like
> > msql and www-data not to be able to access home directories (add
> > "daemon" to their supplementary group list and set the permissions of
> > /home 0705 to root.daemon, perhaps), but is this really worthwhile ?
>
> That would be another violation of general security principles (access
> control based on exlcusion instead of inclusion);
There are obviously differences of opinion in our expectations of
"how secure" a default installation should be.
Should it be locked down like Fort Knox?
Should it be generally usable, and easy for users to see each other's
stuff?
In general, I think it's fair to say that the average Debian
installation does not require Fort Knox levels of security. Simply
allowing other people to read our files is often something desirable;
if I have something especially secret, I'll take steps to make sure
it's not readable or writeable by anyone except me. But in general,
it's not a bad thing that others can see my stuff. I can always keep
private things in a 0700 subdirectory.
Even on the massively shared systems I use, it's common for home
directories to be readable by default, so you can let other people
access your data, scripts, git repos, or whatever.
I can see that in some circumstances you might well want total control
over who can see your files, but unless you're dealing with TOP SECRET
stuff, I am not convinced that this is something the typical user would
wish to have by default. Are there any common use cases which require
this?
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 3:38 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Re: Default Homedir Permissions"):
>> chmod 755 ~ is not a hard way to remove the barrier.
>
> We are arguing about defaults, so this is not a relevant answer.
In both cases it's easy to change permissions, but:
If you start with safe permissions but want to share everything, you
get an error message. Easy to fix.
If you start with unsafe permissions but wanted to share nothing, you
don't get an error messages and your data leaks. Impossible to fix.
>> What are those assumptions based on?
>
> I could ask you the same question. We are arguing in a vacuum.
Feel free to ask.
--
Olaf
--
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/aanlktins21pvtzze5vkczxomabitubunx90bsye-m...@mail.gmail.com
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 01:44:26PM +, Ian Jackson wrote: > Perhaps it might be reasonable to try to find a way for accounts like > msql and www-data not to be able to access home directories (add > "daemon" to their supplementary group list and set the permissions of > /home 0705 to root.daemon, perhaps), but is this really worthwhile ? > If it is, the right thing to do is to go away and think about exactly > how to do it, not to file a bug asking for the default home directory > permissions to be changed. This is easily accomplished using ACLs. Example to only allow apache access to public_html, and nothing else: % setfacl -m g:www-data:x ~ % setfacl -m g:www-data:rx ~/public_html % getfacl ~ ~/public_html getfacl: Removing leading '/' from absolute path names # file: home/rleigh # owner: rleigh # group: rleigh user::rwx group::r-x group:www-data:--x mask::r-x other::r-x # file: home/rleigh/public_html # owner: rleigh # group: rleigh user::rwx group::r-x group:www-data:r-x mask::r-x other::r-x Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 3:58 PM, Roger Leigh wrote: > In general, I think it's fair to say that the average Debian > installation does not require Fort Knox levels of security. Simply > allowing other people to read our files is often something desirable; Does other refer to other users, all other accounts or the entire world? > if I have something especially secret, I'll take steps to make sure > it's not readable or writeable by anyone except me. But in general, > it's not a bad thing that others can see my stuff. I can always keep > private things in a 0700 subdirectory. You can, but you can easily forget that. Note that defaulting to private does not prevent you from changing the permissions. > I can see that in some circumstances you might well want total control > over who can see your files, but unless you're dealing with TOP SECRET > stuff, I am not convinced that this is something the typical user would > wish to have by default. Are there any common use cases which require > this? Like backups, the need for security is often discovered after it was necessary. -- Olaf -- 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/AANLkTim_txyuh+zvXyOXHzWTPf8QypYZHj=s+b4ko...@mail.gmail.com
Re: RFA: all my packages
Hi, On Thu, Feb 10, 2011 at 09:55:48PM -0500, Ryan Kavanagh wrote: > On Thu, Feb 10, 2011 at 07:02:16PM -0500, Yaroslav Halchenko wrote: > > On Thu, 10 Feb 2011, Decklin Foster wrote: > > > rxvt-unicode is a total clusterfuck. > > > > if noone ever comes up (I am already overloaded somewhat) -- I guess > > I will need to look at this cluster..ck since I am using it ;-) > > I don't think I have the time and nor the ability to properly maintain > rxvt-unicode solo, but since it's my terminal of choice, I'm willing to > co-maintain it. I've setup the pkg-urxvt team[0] for the several people interested in helping with the packaging. Please request to join. I'll file an ITA and import the packaging into git shortly. Kind regards, Ryan [0] https://alioth.debian.org/projects/pkg-urxvt/ -- |_)|_/ Ryan Kavanagh | GnuPG key | \| \ http://ryanak.ca/ | 4A11C97A (Transitioning from E95EDDC9) () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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/20110217151754.GA11811@qoppa
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 04:07:12PM +0100, Olaf van der Spek wrote: > On Thu, Feb 17, 2011 at 3:58 PM, Roger Leigh wrote: > > In general, I think it's fair to say that the average Debian > > installation does not require Fort Knox levels of security. Simply > > allowing other people to read our files is often something desirable; > > Does other refer to other users, all other accounts or the entire world? It refers to S_IRWXO, which is what this bug is about. What that means in practice is up to you. > > if I have something especially secret, I'll take steps to make sure > > it's not readable or writeable by anyone except me. But in general, > > it's not a bad thing that others can see my stuff. I can always keep > > private things in a 0700 subdirectory. > > You can, but you can easily forget that. > Note that defaulting to private does not prevent you from changing the > permissions. … > Like backups, the need for security is often discovered after it was > necessary. Yes, but like everything there is a tradeoff. A totally secure system is an unusable system. Having to instruct every user how to relax the permissions to allow others to access their files, or allow their web pages to be visible, is effectively pointless make-work if that was what you wanted in the first place. And for most people, I would argue that /is/ what is wanted. Remember that historically, multi-user systems have been about sharing and collaboration, not isolation in walled-off prisons. I know which type of system I want, and it's not the latter. 0755 is not inherently insecure. Others can't make any changes, but they can look. The only issue here is accidental disclosure of information intended to be private. I would argue that a change that /would/ make a real difference, would be to have (as an example) emblems in Nautilus that flag files and folders depending on if other people have read or write access. That would visually show what is (and is not) secure either by intention or by accident. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Default Homedir Permissions
[Someone] writes ("Re: Default Homedir Permissions"):
> [stuff]
We are in danger of wasting a lot of time with this discussion.
The general pattern is that someone who is unhappy with the state of
the world proposes a substantial change. The worry amongst the rest
of us is that the change might go ahead if we don't oppose it.
So those of us who oppose feel impelled to respond to every message;
whereas the proponent of change is dedicated. There is no natural
conclusion to this argument.
So I would like the maintainers of the adduser package (which seems to
be where the default is mainlys et) to post here to reassure us that
they don't intend to make this change, and that if the maintainers are
thinking of changing their mind they will consult debian-devel.
Ian.
--
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/19805.15206.29837.470...@chiark.greenend.org.uk
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 4:24 PM, Roger Leigh wrote: > On Thu, Feb 17, 2011 at 04:07:12PM +0100, Olaf van der Spek wrote: >> On Thu, Feb 17, 2011 at 3:58 PM, Roger Leigh wrote: >> > In general, I think it's fair to say that the average Debian >> > installation does not require Fort Knox levels of security. Simply >> > allowing other people to read our files is often something desirable; >> >> Does other refer to other users, all other accounts or the entire world? > > It refers to S_IRWXO, which is what this bug is about. What that > means in practice is up to you. Other (people) in "Simply allowing other people to read our files is often something desirable" does not refer to S_IRWXO. >> Like backups, the need for security is often discovered after it was >> necessary. > > Yes, but like everything there is a tradeoff. A totally secure system > is an unusable system. Having to instruct every user how to relax the > permissions to allow others to access their files, or allow their web > pages to be visible, is effectively pointless make-work if that was what > you wanted in the first place. You're right, in that case it makes more sense to edit /etc/adduser.conf Or to setup public dirs that people could use to share stuff without defaulting to share their entire home dir. > And for most people, I would argue that > /is/ what is wanted. Is it? A lot of people have desktops / laptops that aren't shared with other people and that don't use the per-user public_html. > Remember that historically, multi-user systems have been about sharing > and collaboration, not isolation in walled-off prisons. I know which > type of system I want, and it's not the latter. Historically security was not an issue. > 0755 is not inherently insecure. Others can't make any changes, but > they can look. The only issue here is accidental disclosure of > information intended to be private. Right -- Olaf -- 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/AANLkTi=4R87hRmXQc4Y7zL9b5KJ0yJqtTYXeX80MQN=p...@mail.gmail.com
Auditing systems for default homedir permissions and other potential security risks and also for overly long subjects and needlessly antagonistic mailing list discussion threads
On to, 2011-02-17 at 15:24 +, Roger Leigh wrote: > I would argue that a change that /would/ make a real difference, would > be to have (as an example) emblems in Nautilus that flag files and > folders depending on if other people have read or write access. That > would visually show what is (and is not) secure either by intention or > by accident. I'm with Roger and Ian on the default permissions, but that's not why I am making this thread needlessly longer. I am making it needlessly longer because I had a mildly related idea that I am hoping someone will pick up and implement. It would be really cool if there was an automatic auditor for people to use. Not just showing emblems in Nautilus, but offering to fix things as well. Here's how I imagine it might work. You tell the auditor what kind of system this is. d-i would set up a default. For example, personal laptop, or web server, or mail server. You also tell the auditor how much security you want: normal, a lot, or too much. The auditor then looks for things in the system, and in home directories, which might be problems. For example, if it's meant to be a mail server with a lot of security, having telnetd installed and running would be a problem for it to flag. Likewise, it might flag home directory permissions. It then presents the user with a prioritized report, with most urgent things first. The user can then say "I'm ok with this, don't tell me about it again", or "Fix this now, please", or "I don't know what I'm doing, just do something smart", or "I'm suddenly busy, just tell me about this when I ask for a new report". The automatic fixing might do things like remove or disable services, or fix permissions, or install missing security updates, or, on the "too much" security level, wipe all disks and send an e-mail to the nearest secure destruction service to come and pick up the computer and take to it where it can be melted. (If you like the idea, start hacking! I will not get around to this until some other millennium, when I've finished my backup application. I want my backups done before I request my computer to be destroyed.) -- 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/1297957018.22676.40.camel@tacticus
Re: RFA: all my packages
Hi, On 17/02/2011 16:17, Ryan Kavanagh wrote: > I've setup the pkg-urxvt team[0] for the several people interested in > helping with the packaging. Please request to join. I'll file an ITA and > import the packaging into git shortly. Will there be more than the git repo ? If not, why don't you use the collab-maint projet on alioth ? Regards, Vincent > Kind regards, > Ryan > > [0] https://alioth.debian.org/projects/pkg-urxvt/ > -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/4d5d41ac.7000...@free.fr
Re: Bug#613788: ITP: dropbox -- secure backup, sync and sharing util
On Thu, Feb 17, 2011 at 14:52:49 +, brian m. carlson wrote: > On Thu, Feb 17, 2011 at 12:35:26AM -0800, Vincent Cheng wrote: > > * Package name: dropbox > > Version : 1.0.20-1 > > Upstream Author : Dropbox, Inc. > > * URL : http://www.dropbox.com > > * License : Proprietary > > Section : non-free/net > > Description : secure backup, sync and sharing util > > It looks like you're still missing the source for librsync.so.1 in your > packages. Also, I *strongly* recommend that you not include binary-only > shared libraries that are already available in Debian. The security > team will not be very happy with you. As an example, your package > ships libz.so.1, which has been the target of a DSA previously. > The security team doesn't support the non-free section in any way, so not really. Still a bad idea though. Cheers, Julien -- 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/20110217154133.gw12...@radis.liafa.jussieu.fr
Re: Default Homedir Permissions
On Feb 17, Ian Jackson wrote: > I disagree with this conclusion, because I disagree with the > underlying implication that the general readability of files is not > needed. Agreed. > Perhaps it might be reasonable to try to find a way for accounts like > msql and www-data not to be able to access home directories (add > "daemon" to their supplementary group list and set the permissions of > /home 0705 to root.daemon, perhaps), but is this really worthwhile ? We have ACLs, but I believe that the local requirements vary enough that it is not worth the effort. -- ciao, Marco signature.asc Description: Digital signature
Re: Default Homedir Permissions
On Thu, Feb 17, 2011 at 07:14, Ian Jackson
wrote:
> [Someone] writes ("Re: Default Homedir Permissions"):
>> [stuff]
>
> We are in danger of wasting a lot of time with this discussion.
>
> The general pattern is that someone who is unhappy with the state of
> the world proposes a substantial change. The worry amongst the rest
> of us is that the change might go ahead if we don't oppose it.
More simply, the option could be put in the default install instead of
only the expert install. Make the default choice the current behavior,
but let local administrators choose what is best for their system.
--
-Austin
--
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/aanlktimhuo+zpb7opyrkdptd4nmqspdaqba8kq75+...@mail.gmail.com
Re: Default Homedir Permissions
Austin English writes ("Re: Default Homedir Permissions"):
> On Thu, Feb 17, 2011 at 07:14, Ian Jackson
> wrote:
> > [Someone] writes ("Re: Default Homedir Permissions"):
> >> [stuff]
> >
> > We are in danger of wasting a lot of time with this discussion.
> >
> > The general pattern is that someone who is unhappy with the state of
> > the world proposes a substantial change. The worry amongst the rest
> > of us is that the change might go ahead if we don't oppose it.
>
> More simply, the option could be put in the default install instead of
> only the expert install. Make the default choice the current behavior,
> but let local administrators choose what is best for their system.
Your reply doesn't seem to be a way of avoiding wasting time, I'm
afraid, but rather a way of perpetuating the discussion.
But at the risk of doing the same myself: increasing the priority of
installation questions is not without costs. I think that the current
default suits a big enough proportion of our users that it should be
kept at the current priority.
Ian.
--
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/19805.20948.449432.456...@chiark.greenend.org.uk
Re: Default Homedir Permissions
On Thu, 2011-02-17 at 15:24 +, Roger Leigh wrote: > Yes, but like everything there is a tradeoff. A totally secure system > is an unusable system. Having to instruct every user how to relax the > permissions to allow others to access their files, or allow their web > pages to be visible, is effectively pointless make-work if that was > what > you wanted in the first place. And for most people, I would argue > that > /is/ what is wanted. You don't want to make it harder for users, but this is where design can help. If we need to make a system which prevents cross user file attacks, then we could fairly easily implement these things: * Shared Folder, directory which is available to all users where they can put explicitly shared contents (MacOSX does this). * Make sure shared folders via smb/nfs are accessible, make it clear that this would share files inside the system as much as on the network. * A program which allows temporary file access to another user's home folder after the user have authorised the access. > Remember that historically, multi-user systems have been about sharing > and collaboration, not isolation in walled-off prisons. I know which > type of system I want, and it's not the latter. Yes, but we don't make it clear that a user's home directory is a free-for-all with all users. Folder indicators would be useful. But do users know that they've signed up for this when they installed Ubuntu? I think it's more likely that Ubuntu users think the data is protected until the magic time when cross-user file access is demanded and then it's unprotected for that one instance. Computers are magic after all. Asking users would be key to answering that. > 0755 is not inherently insecure. Others can't make any changes, but > they can look. The only issue here is accidental disclosure of > information intended to be private. If public by default is the way we want to go, then why not have a Private folder be default in the users home directory? Combined with the indication emblem in nautilus; this might provide a space for users to put data. ATM it's too hard to teach users how to secure a folder or even how to set up an encrypted folder. Martin, -- 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/1297961716.28341.10.camel@delen
Re: RFA: all my packages
]] Vincent Danjean | On 17/02/2011 16:17, Ryan Kavanagh wrote: | > I've setup the pkg-urxvt team[0] for the several people interested in | > helping with the packaging. Please request to join. I'll file an ITA and | > import the packaging into git shortly. | | Will there be more than the git repo ? If not, why don't you use the | collab-maint projet on alioth ? The request said they'll use at least a mailing list, else I wouldn't have approved it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/8739nm7d2f@qurzaw.varnish-software.com
Re: for those who care about unbound (resolvconf and DNSSEC)
On 02/17/2011 09:46 AM, Robert Edmonds wrote: > 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. thanks. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- 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/4d5d789e.6040...@progress-technologies.net
Bug#613857: RFA: cacti + cacti-spine
Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Due largely to the fact that I'm no longer using cacti on a regular basis, I think cacti and spine should get a new maintainer. Both packages are relatively up to date and in decent shape, and the upstream authors are responsive and pleasant to work with. I'm also open to starting up an alioth project for co-maintenance, and can sponsor/review uploads for a while if there's interested people who are not (though preferably are interested in becoming) uploading developers. Sean -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1demoACgkQynjLPm522B1ETgCfYbs7VRKu4tCyKj8B9W8pYxUJ 4msAn0e0m/HqoCAIlAkIQyTTTIeNanwx =c2E4 -END PGP SIGNATURE- -- 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/20110217194347.29062.34035.reportbug@minnika
Bug#613870: RFA: libraw -- raw image decoder library
Package: wnpp Severity: normal X-Debbugs-CC: debian-devel@lists.debian.org I request an adopter for libraw source package. It is one of the build-dependencies of shotwell package. Package: libraw-dev Description: raw image decoder library (development files) LibRaw is a library for reading RAW files obtained from digital photo cameras (CRW/CR2, NEF, RAF, DNG, and others). This package contains a static library and header files. Package: libraw-doc Description: raw image decoder library (documentation) LibRaw is a library for reading RAW files obtained from digital photo cameras (CRW/CR2, NEF, RAF, DNG, and others). This package contains documentation files. -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
Re: Default Homedir Permissions
On 02/17/2011 10:55 AM, Martin Owens wrote: On Thu, 2011-02-17 at 15:24 +, Roger Leigh wrote: Yes, but like everything there is a tradeoff. A totally secure system is an unusable system. Having to instruct every user how to relax the permissions to allow others to access their files, or allow their web pages to be visible, is effectively pointless make-work if that was what you wanted in the first place. And for most people, I would argue that /is/ what is wanted. You don't want to make it harder for users, but this is where design can help. If we need to make a system which prevents cross user file attacks, then we could fairly easily implement these things: * Shared Folder, directory which is available to all users where they can put explicitly shared contents (MacOSX does this). Speaking as a (non-Unix) (non-DD and so no authority here) Administrator who is constantly pestered by auditors & CISO reviews, I agree with Olaf, and think that Shared Folder is a good way to make this explicit. -- "The normal condition of mankind is tyranny and misery." Milton Friedman -- 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/4d5d9ded.2080...@cox.net
Re: Default Homedir Permissions
On 02/17/2011 08:58 AM, Roger Leigh wrote: [snip] Should it be locked down like Fort Knox? There's a heck of a lot of middle ground between "Fort Knox" and "Hippy Commune". Should it be generally usable, and easy for users to see each other's stuff? Only with the owner's permission. Privacy, remember? It's why we encrypt Wi-Fi and https exists. -- "The normal condition of mankind is tyranny and misery." Milton Friedman -- 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/4d5d9eb1.80...@cox.net
Re: Default Homedir Permissions
On 02/17/2011 09:24 AM, Roger Leigh wrote: [snip] Yes, but like everything there is a tradeoff. A totally secure system is an unusable system. Why the black and white? What happened to grey? Having to instruct every user how to relax the permissions to allow others to access their files, or allow their web pages to be visible, is effectively pointless make-work if that was what you wanted in the first place. And for most people, I would argue that /is/ what is wanted. Most people want "easy". It's why Windows is malware central. Remember that historically, multi-user systems have been about sharing and collaboration, not isolation in walled-off prisons. I know which type of system I want, and it's not the latter. I thought it was about sharing expensive resources. (But then, I come from a DP background.) -- "The normal condition of mankind is tyranny and misery." Milton Friedman -- 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/4d5da07d.9020...@cox.net
RFC: bringing back task packages
A long time ago, tasksel installed task packages, which were regular metapackages. This was dropped because the task packages had to Depend on many packages, which made the installed system brittle, and made testing propigation a problem. Now that Recommends are installed by default, I'm revisiting the idea of using task packages. It solves many issues and inconsistencies with tasksel vs the rest of Debian. The other problem with task packages before is that tasksel allowed the user to select from amoung all that were available, and this resulted in a confusing long mess of tasks to choose from. To avoid that, I intend to keep the ultimate decision about what tasks are displayed in tasksel under the control of the tasksel maintainers. But, I do hope that moving more of the maintenance of tasks to the developers responsible for those areas of Debian will result in a better selection of software and less work. We've already had some good progress in that area with the gnome metapackages which are used by tasksel. If tasksel was switched to task packages, the task packages would probably be initially built from tasksel's source. They could be split out of tasksel's source as other groups stepped up to maintain them. ## Questions for teams ### gnome Would the gnome team want to maintain a task-gnome? Much of tasksel's gnome task is already taken from the gnome-core and gnome metapackages, with a few more things added. task-gnome would not need to deal with core X desktop stuff; task-desktop would still handle that. Although we could move away from having a task-desktop if you'd prefer. There are also many localized desktop tasks. Mostly these add things like localization packages for openoffice, and occasionally some fonts. I'd like to see those be maintained in conjunction with task-gnome, but it would mean some coordination with the dozens of people who currently maintain those localization tasks. ### kde, lxde, xfce See above and s/gnome/$you/ ### cups Would the cups maintainers be interested in maintaining a task-print-server? Keeping the right ppds and cups packages in the task has been an ongoing issue for me. Note that a subset of cups is also installed as part of the desktop tasks, and it would also make sense to have a metapackage on the cups side that desktop tasks could use. The sole different currently is that openprinting-ppds is included in the print server task, but not the desktop tasks. ### blends I think there is interest in getting some blends displayed in Taskel? It's mostly orthagonal to this proposal, but this would help with giving you full control over what your tasks do. I do feel that blends need to be listed below the other tasks in tasksel, and probably with a divider between them. Also, we have been careful to only have ten tasks, to avoid overloading the user; and there is a limit to the length of the list before it begins scrolling, so the d-i team would have to look at the UI before adding Blends to the interface. ### i18n There are many language tasks in tasksel. It might be good to have the task packages be moved out of tasksel; I don't know if it'd make sense to have individual language teams maintain them, or what. If tasksel displayed Task packages' short Description fields, those would need to be translated. I know we have translated Descriptions but I don't know about coverage, or if that info is available when tasksel runs in d-i? ## Comparing tasksel and dpkg fields Key -> Depends This would be an improvement, as new Depends of a task would be installed on upgrade; there is currently no way to upgrade a task and get new packages that have been added to it. Note that Britney already treats Key as Depends internally. So this change would not impact testing migration. Packages -> Recommends Recommends may be better than what we have now in tasksel. If aptitude auto-selects *new* recommends of a previously installed package to be installed? Currently new Packages added to a task only affect new installations of that task. Most packages in a task need to be Recommends, to avoid wedging Britney, and to allow removing bits of a task that are not wanted. Note that the Task field on the package side, which is added to the archive based on data from tasksel, could go away. Enhances -> ??? The Enhances fields are not truely the same as Depends (but are probably closer to Depends than to dpkg's Enhances). A task that Enhances other tasks is hidden, and auto-force-installed when the other tasks are installed. Relevance -> ??? This is used to do some UI ordering of tasks. Closest equivilant is Priority, but it's not granular enough. Test- -> ??? These fields specify programs to run to test if the task should be force-auto-installed, or hidden, or selected for installation. Descrip
printer server task in the installer?
A Quinta 17 Fevereiro 2011 23:20:30 Joey Hess você escreveu: [...] > Note that a subset of cups is also installed as part of the desktop > tasks, and it would also make sense to have a metapackage on the cups > side that desktop tasks could use. The sole different currently is > that openprinting-ppds is included in the print server task, but not > the desktop tasks. [...] If the installer will present no more than a few tasks during installation to not overload the user i think this task can be left out of the installer and be installed after. It's a very specific and no so common task imho. -- Melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.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/201102172348.28133.el...@debianpt.org
Re: Default Homedir Permissions
Martin Owens wrote: > If public by default is the way we want to go, then why not have a > Private folder be default in the users home directory? Combined with the > indication emblem in nautilus; this might provide a space for users to > put data. ATM it's too hard to teach users how to secure a folder or > even how to set up an encrypted folder. IIRC, Ubuntu has done some work toward providing such an encrypted private subdirectory by default. Someone should look into pulling that into a package in Debian. -- see shy jo signature.asc Description: Digital signature
Re: RFC: bringing back task packages
Le Thu, Feb 17, 2011 at 07:20:30PM -0400, Joey Hess a écrit : > > ### blends > > I think there is interest in getting some blends displayed in Taskel? > It's mostly orthagonal to this proposal, but this would help with > giving you full control over what your tasks do. I do feel that blends > need to be listed below the other tasks in tasksel, and probably with > a divider between them. Also, we have been careful to only have ten > tasks, to avoid overloading the user; and there is a limit to the length > of the list before it begins scrolling, so the d-i team would have to > look at the UI before adding Blends to the interface. Dear Joey, it would be very exciting to have the possibility to select a blend at the installation. To circumvent the limitation of space, how about having a single line to select ‘Chose a Debian Pure Blend‘, that would lead to a page that provides the full list of blends ? > ### i18n > > There are many language tasks in tasksel. It might be good to have > the task packages be moved out of tasksel; I don't know if it'd make > sense to have individual language teams maintain them, or what. On the other hand, I would warmly welcome an i18n task that reproduces the user experience on Macintoshes, where a standard system contains everything to read and write a large number of languages. Currently with Debian, on fresh installs, I have to iterate over the missing fonts for Japanese and other Asian languanges, and look back on my old notes to figure out what packages will provide me an input system for chinese characters, because I select French or English at install time. 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 Archive: http://lists.debian.org/20110218013916.gb...@merveille.plessy.net
Re: RFC: bringing back task packages
On Fri, Feb 18, 2011 at 9:39 AM, Charles Plessy wrote: > it would be very exciting to have the possibility to select a blend at the > installation. To circumvent the limitation of space, how about having a single > line to select ‘Chose a Debian Pure Blend‘, that would lead to a page that > provides the full list of blends ? Being able to install blends from d-i would indeed be cool. Seems to me that there could be potentially many many tasks for the blends. For e.g. there are 19 tasks in the Debian Med blend. There are hundreds of Debian derivatives and many of these could become Debian Pure Blends with some work. I would suggest some sort of search field would be the way to go, browsing any list of blend tasks is going to be a pain. Maybe a drill-down UI would also work, grouping tasks based on audience; 'I am a scientist', 'I research medicine', 'I research epidemiology', oh cool I should install tasks-med-epi to get some tools (which are foo, bar & baz) for that. Maybe a combination of these is the way to go. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/aanlktims7b6vs-smu6yeh2-+vnqoevwrvbxtqekfm...@mail.gmail.com
squeeze-updates during Squeeze installation
Hello, During Squeeze installation process, since volatile archive was replaced with squeeze-updates and error of unreachable archive occurs. Of course installation process can be continued without any consequences, but I'm guessing installer should be updated so new users don't get confused with this error message. If this was "fixed" in meantime, please disregard this email. Adnan -- 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/AANLkTinB9j7uhMT9RSuxMZCw5hcR2VSWc7Q27B5+=h...@mail.gmail.com
Bug#613898: ITP: vargs -- function argument handling for Node
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: vargs Version : 0~20100516-1 Upstream Author : Alexis Sellier * URL : https://github.com/cloudhead/vargs * License : Expat Programming Lang: JavaScript Description : function argument handling for Node Node is an event-based server-side JavaScript engine. . vargs provided variable argument handling for Node functions taking a callback. -- 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/20110218022631.14518.29971.reportbug@localhost.localdomain
how come the buildd machines can't find python-vtk?
I uploaded insighttoolkit the other day, but the buildd machines refuse to build it, claiming an installability problem [1]: insighttoolkit/alpha dependency installability problem: insighttoolkit (= 3.20.0-8) build-depends on one of: - python-vtk (= 5.4.2-8) This is repeated for all architectures. Two things puzzle me: 1. python-vtk is still in the archive according to the PTS and "rmadison" 2. the above output says "(= 5.4.2-8)", but the build-dep isn't versioned What's going on? Thanks, -Steve [1] https://buildd.debian.org/status/package.php?p=insighttoolkit signature.asc Description: Digital signature
Re: squeeze-updates during Squeeze installation
(Moving to debian-b...@lists.debian.org where it's more appropriate) On Fri, 18 Feb 2011, Adnan Hodzic wrote: > Hello, > > During Squeeze installation process, since volatile archive was > replaced with squeeze-updates and error of unreachable archive occurs. > Of course installation process can be continued without any > consequences, but I'm guessing installer should be updated so new > users don't get confused with this error message. I also saw this error message but only under special circumstances. I believe when I installed from a DVD and selected to not use a mirror. It's still somewhat disturbing. Maybe we should keep an empty "stable" archive on volatile.debian.org in the mean time. 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/20110218073017.gf13...@rivendell.home.ouaza.com
