Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
Le mercredi 08 septembre 2010 à 01:33 +0200, Salvo Tomaselli a écrit : > On Tuesday 07 September 2010 15:18:26 Josselin Mouette wrote: > > No. gnome-user-share does not need root permissions. > I use kde. After installing your gnome-user-share it i couldn't find how to > start it. I found a configuration window but netstat -l doesn't show anything > listening. Have you considered, I don’t know… starting the daemon? There used to be similar software for KDE (kpf). I don’t know what happened to it, though. > Also no man page provided -> too complex for me, really. Have you considered, I don’t know… looking at the documentation? Manual pages are not a useful documentation system for GUI programs, which is why many upstreams don’t care about them anymore. > The netcat thing is much easier. At least man nc exists. No comment. > > Well that’s usually the case when you don’t have root permissions. > Long example: > i own a box that has no screen and uses ssh. There are many entries in > /etc/shadow but only one of the users knows the root password. And you want your users to start random webservers on random TCP ports on this box to share their files? Way to go. I’m happy you’re not administrating my network. > > Maybe we could increase the distribution quality by requiring anyone > > making an ITP to be part of a core package’s maintenance team. > You could indeed suggest that, but some people just don't have enough time or > skills to be usefull in a core package, and your proposal wouldn't lead to a > better maintenance of core packages but just to the dropping of less > important > packages. This would already reduce the load on the FTP, release and security teams, and allow their members to do more useful things. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1283930904.19864.9.ca...@meh
Bug#596042: ITP: logbook -- logging replacement for Python
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: logbook Version : 0.2 Upstream Author : Armin Ronacher * URL : http://logbook.pocoo.org/ * License : BSD Programming Lang: Python Description : logging replacement for Python Simple logging library that aims to support desktop, command line and web applications alike. It can send your logs directly to database (all supported by SQLAlchemy, MongoDB), Twitter, Libnotify, syslog, file, mail, etc. -- 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/20100908075119.3008.93517.report...@vega.piotro.eu
Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On 07.09.2010 11:17, Salvo Tomaselli wrote: On Tuesday 07 September 2010 10:47:08 Josselin Mouette wrote: Oh, please. If you want to setup such schemes, why would you not want to spend 5 minutes to configure apache or lighttpd instead of spending at least the same time to configure such an obscure piece of software? If all you care about is sharing a few files in the simplest way, there are much better tools to do it, like gnome-user-share. 1 you are assuming to have root permissions (read my previous email) What is the problem? You need the root permission to install the package. And IMHO a sysadmin is needed to evaluate the security and global policies. BTW 12-15 years ago my university set up on out home a "public_html" personal directory, accessible with "http://somehost/~myusername/";. Is not what you call easy method to allow user to publish few files? [BTW also people.debian.org has such setup. Not complex] Now the "host/~username" is not very frequent, but it works on nearly every real webserver. 2 you are assuming to be working on a desktop My solution don't assume that. 3 you are assuming you want to share the same file all the time. But this might not be the case, and change the configuration every time you want to share a different file could annoying. The classical solution don't require that. The advantage: you have a real server, protected from DoS (and multiple connections), protected by random and wrong requests. You can have automatically compressed output (to reduce traffic, thus speed on slow connections) etc. You are protected by url containing /../ (not to go below the authorized home), with %xx escape etc. ciao cate -- 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/4c874887.2070...@debian.org
Re: Bugs in Backported Packages
Hi, On Tue, Sep 07, 2010 at 02:09:24PM -0700, Russ Allbery wrote: > Steve Langasek writes: > > > For the package in question, the backports are done by a fellow > > comaintainer, so I'm not complaining about the bug traffic; but that > > doesn't mean it's *right* for that traffic to be going to the BTS by > > default. > > I wonder if we could apply some logic such as if the backports uploader is > also listed in Maintainer or Uploaders for the regular Debian package, > send the bug reports to the BTS, otherwise send them to backports-users > and the backport uploader. I would object to that, too. That would equally make "all bpo bugs go to the BTS" in my case. Thanks, but no, thanks. Especially not if the "bug" is caused by a external package and/or debhelper backported but its scripts not adapted back to lenny so that e.g. the built packages don't call update-mime-database. I don't think Joey will be happy if I reassigned this bug to debhelper, even with a + backports tag. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- 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/20100908083312.ge8...@rene-engelhard.de
Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On Tue, Sep 7, 2010 at 15:18, Josselin Mouette wrote: > Le mardi 07 septembre 2010 à 11:17 +0200, Salvo Tomaselli a écrit : >> On Tuesday 07 September 2010 10:47:08 Josselin Mouette wrote: >> > Oh, please. If you want to setup such schemes, why would you not want to >> > spend 5 minutes to configure apache or lighttpd instead of spending at >> > least the same time to configure such an obscure piece of software? >> > >> > If all you care about is sharing a few files in the simplest way, there >> > are much better tools to do it, like gnome-user-share. >> >> 1 you are assuming to have root permissions (read my previous email) > > No. gnome-user-share does not need root permissions. > >> 2 you are assuming to be working on a desktop > > Well that’s usually the case when you don’t have root permissions. > >> 3 you are assuming you want to share the same file all the time. But this >> might not be the case, and change the configuration every time you want to >> share a different file could annoying. > > That’s precisely why gnome-user-share was written. Thanks for making my > point. > > Now if you could give a hand in maintaining important packages, like > apache2 and its 90 open bugs, it would help more than packaging your pet > web server which will be of use for at best 2 users. If there's two options: (a) someone packages obscure software for Debian (b) me having to go to obscure software's website and run "setup.py" myself I'll choose (a) any day. I find it highly convenient when I hear of some piece of software, and discover that it's just an "apt-get install" away. Would be nice to have more maintainers for core packages, but what if it's just not interesting. I'll rather have the uninterested hacker package something new, than not do anything at all for Debian. If you are worried about package quality, burden on security team, blah, I expect an RC bug will be filed and so that the package can be removed from Testing. If it's neglected, then it can be removed from Unstable. Let Debian be the wonderful supermarket it is. -- blog: http://tshepang.tumblr.com -- 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/aanlktinwj0kqxq54jztfrwoyuhnvic==eyahxqc07...@mail.gmail.com
ClamAV supportability in stable release (was: Unidentified subject!)
Hi all, (Dared to fix CC/Subject which seemed to be somewhat broken in initial email.) > The release team have been asked to remove ClamAV from testing (and > hence the next stable release. See bug #587058. > > The issue seems to be that it's not supportable in stable due to the > upstream maintainers deciding to upgrade their data files in a way that > isn't binary compatable with previous versions. > > A couple of options have been mentioned for what to do with this, > including volatile. I'm opening this mail thread for discussion, and if > no one comments then I'll go ahead and action the bug report in two > weeks. For avoidance of doubt, this will also affect reverse > depends, see dd-list below. > [...] Has there been feedback other than Christian's idea of adding a kind-of-transitional package? Speaking as clamav maintainer, we'll happily continue to upload to unstable, and if migration to testing (and stable) is permitted - so be it, but the volatile-path seems to be a lot more promising and future-proof. That said, the clamav ABI/API is surely stabilizing and hence users of clamav packages from stable might be better off than before. But there's no guarantee that they really get all the latest&greatest detection capabilities. One clear volatile-only advantage is added cleanliness: No need to mess around with different versions that actually are the same packages, and it just feels a lot better if we can have a package in volatile only, and not in unstable as well. Best, Michael pgpA9ZtKYzQTd.pgp Description: PGP signature
Re: ClamAV supportability in stable release (was: Unidentified subject!)
Sorry, debian-rele...@bugs.d.o really doesn't exist... > Hi all, > > (Dared to fix CC/Subject which seemed to be somewhat broken in initial email.) > > > The release team have been asked to remove ClamAV from testing (and > > hence the next stable release. See bug #587058. > > > > The issue seems to be that it's not supportable in stable due to the > > upstream maintainers deciding to upgrade their data files in a way that > > isn't binary compatable with previous versions. > > > > A couple of options have been mentioned for what to do with this, > > including volatile. I'm opening this mail thread for discussion, and if > > no one comments then I'll go ahead and action the bug report in two > > weeks. For avoidance of doubt, this will also affect reverse > > depends, see dd-list below. > > > > [...] > > Has there been feedback other than Christian's idea of adding a > kind-of-transitional package? Speaking as clamav maintainer, we'll happily > continue to upload to unstable, and if migration to testing (and stable) is > permitted - so be it, but the volatile-path seems to be a lot more promising > and > future-proof. That said, the clamav ABI/API is surely stabilizing and hence > users of clamav packages from stable might be better off than before. But > there's no guarantee that they really get all the latest&greatest detection > capabilities. > > One clear volatile-only advantage is added cleanliness: No need to mess around > with different versions that actually are the same packages, and it just > feels a > lot better if we can have a package in volatile only, and not in unstable as > well. > > Best, > Michael > pgpOOv2RN3f3z.pgp Description: PGP signature
师你好！我换联系号码了%
ÄãºÃ£¡ ÎÒ¹«Ë¾£I´úÀíÈ«ø¸÷µØ¸÷·N(ø¡¢µØ) @�...@r°l%_/ƱL/ Ë°µãµÍÁ®£¬¿É²éÔ»òò×CáḶ/¿î, ÓÐÐèÒªÕíµçÂϵ£º µç»° £º¡¾ 135 1012 4818 ¡¿ Q Q£º ¡¾623 292 963 ¡¿ СÕÅ -- 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/20100908130104.ef8ce2d8...@liszt.debian.org
Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On Wednesday 08 September 2010 09:28:24 Josselin Mouette wrote: > Le mercredi 08 septembre 2010 à 01:33 +0200, Salvo Tomaselli a écrit : > > On Tuesday 07 September 2010 15:18:26 Josselin Mouette wrote: > > > No. gnome-user-share does not need root permissions. > > > > I use kde. After installing your gnome-user-share it i couldn't find how > > to start it. I found a configuration window but netstat -l doesn't show > > anything listening. > > Have you considered, I don’t know… starting the daemon? Can you tell me where exactely the following page mentions a daemon or any other command i could run? http://library.gnome.org/users/gnome-user-share/stable/gnome-user-share- getting-started.html.en > Have you considered, I don’t know… looking at the documentation? Manual > pages are not a useful documentation system for GUI programs, which is > why many upstreams don’t care about them anymore. Yes, i also did, of course. > And you want your users to start random webservers on random TCP ports > on this box to share their files? Way to go. I’m happy you’re not > administrating my network. Maybe the server is not on internet... > This would already reduce the load on the FTP, release and security > teams, and allow their members to do more useful things. And would lead many people to choose other distributions that offer more than merely core packages. Bye -- Salvo Tomaselli signature.asc Description: This is a digitally signed message part.
Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On 2010-09-08, Salvo Tomaselli wrote: >> This would already reduce the load on the FTP, release and security >> teams, and allow their members to do more useful things. > And would lead many people to choose other distributions that offer more > than merely core packages. Could people please stop telling everybody that somebody else might switch to Ubuntu, Fedora, Gentoo or whatever because their pet feature is not implemented? It's silly. 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/slrni8fma0.35r.tr...@kelgar.0x539.de
Re: Bugs in Backported Packages
On Wed, 08 Sep 2010, Rene Engelhard wrote: > That would equally make "all bpo bugs go to the BTS" in my case. Thanks, but > no, > thanks. Especially not if the "bug" is caused by a external package and/or > debhelper > backported but its scripts not adapted back to lenny so that e.g. the built > packages > don't call update-mime-database. If the bug is found in the appropriate version and tagged appropriately, then it's trivial to ignore and/or exclude. The main reason to have the bugs filed in the BTS is so that it's easy to promote them from a case where the bug is "bpo only" to the case where the bug affects all versions of the package. > I don't think Joey will be happy if I reassigned this bug to > debhelper, even with a + backports tag. That's not a bug in debhelper; it's a bug in the backport of the package, so it shouldn't be filed against debhelper. [Though, perhaps it could be a wishlist request; I don't know.] Don Armstrong -- The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. -- Douglas Adams _Mostly Harmless_ http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100908190423.gc28...@teltox.donarmstrong.com
Re: Bugs in Backported Packages
On Wed, Sep 08, 2010 at 12:04:24PM -0700, Don Armstrong wrote: > That's not a bug in debhelper; it's a bug in the backport of the > package, so it shouldn't be filed against debhelper. [Though, perhaps > it could be a wishlist request; I don't know.] No, it's a bug in the debhelper backport. If backported to lenny it should revert stuff like * dh_desktop: Now a deprecated no-op, since desktop-file-utils uses triggers. Closes: #523474 so that the dh_ tools still do what their manpage says and what is expected from them. (IMHO) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- 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/20100908192146.ga29...@rene-engelhard.de
Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On Wed, Sep 08, 2010 at 08:03:14PM +0200, Salvo Tomaselli wrote:
> > This would already reduce the load on the FTP, release and security
> > teams, and allow their members to do more useful things.
> And would lead many people to choose other distributions that offer more than
> merely core packages.
Salvo, I do appreciate how much you care about this package, but I don't
think the past, say, 15 messages of "lateral" discussion in this thread
have helped at all the cause of woof. I'm of course biased, but I've the
impression that the main points to be addressed are still the one raised
in my earlier post in this thread.
That is: considering that introducing a new web server in the archive
will potentially increase the work of the security team, it must be
worth. To verify it is worth or not there is only one way: perform a
thorough review of alternatives already present in the archive and point
out the unique features (of all kind, including user interface
difference) of woof with respect to them. Bonus points: mention those
unique feature in the long description as help for sysadms having to
choose woof among others.
I haven't yet seen either you, or the ITP-er, or anyone else doing that
and I've the impression you'll be getting nowhere until that is done.
/me and his last post on this thread
Cheers.
PS As a not very thorough personal suggestion of mine, and after a bit
of Googling, I'd start from the "webfs" package to document what more
woof has to offer.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bugs in Backported Packages
On Wed, 08 Sep 2010, Rene Engelhard wrote: > On Wed, Sep 08, 2010 at 12:04:24PM -0700, Don Armstrong wrote: > > That's not a bug in debhelper; it's a bug in the backport of the > > package, so it shouldn't be filed against debhelper. [Though, perhaps > > it could be a wishlist request; I don't know.] > > No, it's a bug in the debhelper backport. Whatever package the bug actually exists in,[1] the underlying point is the same. The bug would be marked as affecting a version branch which wasn't distributed by Debian, and it can be easily ignored by the maintainer of either package. With the addition of a tag to even further separate out these bugs, it can be further ignored. If the default case ends up being that people don't want to receive these bug messages, then we can even filter them out by default at the BTS level. Doesn't really matter to me. Don Armstrong 1: It's certainly a bug in the backported package using debhelper improperly; it may also be an additional wishlist bug in debhelper. -- Grimble left his mother in the food store and went to the launderette and watched the clothes go round. It was a bit like color television only with less plot. -- Clement Freud _Grimble_ http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100908202224.gw22...@rzlab.ucr.edu
Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
Stefano Zacchiroli wrote: > That is: considering that introducing a new web server in the archive > will potentially increase the work of the security team, it must be > worth. You know, introducing any package that is capable of network traffic in either direction can potentially increase the work of the security team. What this thread appears to be missing is any acknowledgement of the degrees of potential security impact that exist between apache and say, wget. An exploitable hole in apache's default configuration has the impact of massive worms doing real damage to the internet and exposing vast amounts of information to black hats, etc. Organisations exist that will pay a nice sum of money for zero-day access to such a security hole. An exploitable hole in wget is likely only "exploitable" in theory, or with much effort and luck. I doubt you could find anyone who'd pay you $10 for zero-day access to such a hole. The woof package seems likely to have a total security impact that is actually less than wget, since fewer people will be using it, and its use will be limited to more peer-to-peer situations. I have found a security hole in woof. How much will someone pay me to disclose it? [1] AFAICS, woof is unique in both its strategy of serving a file only 1 (or N times), and its trivial command-line invocation on a single file. I'd use it. Incoming code of possible security significance should be reviewed for at least common classes of security holes. Instead, we get a thread where the ITPer is required to prove that nothing in Debian can do what his package does. Personally, I feel that our culture of ripping ITPs to shreds has gone too far, and needs to be reigned in, while our culture of actual, useful security impact analysis and review is stunted. -- see shy jo, who has written a small, stupid, badly designed web server with no unique or redeeming features, and gotten it into Debian :P [1] I've emailed the author, so it won't be zero-day for long. Buy now! signature.asc Description: Digital signature
