Fun job: Please test/review patch for picocom CVE-2015-9059

Hi security, there is a problem with the picocom terminal emulator: picocom before 2.0 has a command injection vulnerability in the 'send and receive file' command because the command line is executed by /bin/sh unsafely. (https://security-tracker.debian.org/tracker/CVE-2015-9059) The bug

Re: Handling of "malware" in Debian

On 2016-11-10 09:45, Paul Wise wrote: > My intuition says that there are users who don't have apt-listchanges > installed or don't read the NEWS files. The most likely place folks > will see the notification is in the UI of the malware package itself. This is true. OTOH, if the WOT UI is gone,

Re: [Pkg-mozext-maintainers] Handling of "malware" in Debian

On 2016-11-09 19:34, Ximin Luo wrote: > Context for the new list you added, please? #842939 Is it OK, if I do the upload? I'm in the team, but David Prévot did previous uploads. Cheers

Re: Handling of "malware" in Debian

Quoting Holger Levsen : i'm not sure about the releasing with stretch part. Maybe it would be better to have the updated, empty package in stretch in 5plusX days and then remove it before the release, say on January 1st. Ah, OK. Understood. Well, maybe As Short As

Re: Handling of "malware" in Debian

Quoting Holger Levsen : I think so. And I also think this should be done. and, who's gonna file the RM bug for unstable? I would RM for buster, because users of stretch might already be affected.

Re: Handling of "malware" in Debian

Quoting Paul Wise : A new empty package would be better than just removing it but the user would not get any notification about why the functionality is gone nor any information about the privacy violations they were subject to. Would NEWS.Debian be sufficient?

Handling of "malware" in Debian

Hi, because of the WOT[*] incident, I wonder how Debian should handle malware packages in favour of our users. The current scheme is to remove the offending package from stable and go along. With unattended-upgrades or other automatic upgrade schemes, such packages would remain on many systems

Re:

On 2015-05-11 22:33, Johannes Wolpers wrote: htmlhead/headbodydiv style=font-family: Verdana;font-size: 12.0px;divI will dominate this world one day Please do not send HTML formatted email to mailing lists. It makes them difficult to read for us mutt users. Dankeschön! -- To UNSUBSCRIBE,

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

On 2014-09-24 23:05, Hans-Christoph Steiner wrote: * the signature files sign the package contents, not the hash of whole .deb file (i.e. control.tar.gz and data.tar.gz). So preinst and friends would not be signed? Sounds dangerous to me. -- To UNSUBSCRIBE, email to

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

On 2014-09-21 20:04, Elmar Stellnberger wrote: A package with some new signatures added is no more the old package. It should have a different checksum and be made available again for update. Perhaps someone wants to install the package not before certain signatures have been added. If a

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

On 2014-09-21 21:13, Richard van den Berg wrote: Package formats like apk and jar avoid this chicken and egg problem by hashing the files inside a package, and storing those hashes in a manifest file. Is there a chicken and egg problem? Only if one insists on embedding the signatures in one

PPA security (was: Debian mirrors and MITM)

Quoting Jeremie Marguerie jere...@marguerie.org: Thanks for bringing that issue! I feel the same way when I install a packet from a non-official PPA. Unfortunately, every package can do anything: pre-inst, post-inst, pre-rm, post-rm run as root. If you don't trust a PPA the same way you trust

Re: md5 hashes used in security announcements

On 2008-10-25 07:09, Felipe Figueiredo wrote: Can anyone please explain why that long list of links and filenames is interesting, or point to a link that does? I assume, it's tradition from the times, when only few people used apt-get and friends (and many years apt-get did not have signature

Re: antivirus for webserver

On 2008-10-06 21:57, R. W. Rodolico wrote: And, install a good log summary program and read the results religiously. I use visitors. Would you suggest another one? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: Password leaks are security holes

On 2008-08-28 13:05, Johan Walles wrote: It's readable by anybody with physical access to the hardware. If their have physical access to the hardware, auth.log would be my least worry. That doesn't mean Debian should *help* root doing that in a default install. Security by default, anybody?

DNS and cats: Password leaks are security holes

On 2008-08-28 20:40, Simon Valiquette wrote: That's obviously true, but that doesn't cover the case when logs are copied to a second system with sysadmins that doesn't have access to the first server. And if someone use the standard 514 syslog port instead of using an SSL tunnel or the

Re: Find installed contrib and non-free packages

On Thu, Jun 12, 2008 at 11:38:33AM +0200, Filip Husak wrote: I think the following command resolves your problem: for pkg in `dpkg -l | grep ii | awk '{print $2}'` ; do if [ `apt-cache show $pkg | grep 'contrib\|non-free' | wc -l` -ne 0 ]; then echo $pkg; fi; done You should grep for

Re: Find installed contrib and non-free packages

On Thu, Jun 12, 2008 at 12:27:12PM +0200, Vladislav Kurz wrote: 1. remove contrib and non-free from /etc/apt/sources.list 2. run dselect (update, select) and you will see all contrib and non-free packages as obsolete/local packages. Good, because it will show other suspects as well. E.g.

Re: Find installed contrib and non-free packages

On Fri, Jun 13, 2008 at 07:40:15AM +1000, Andrew Vaughan wrote: On Friday 13 June 2008 07:17, Andrew Vaughan wrote: In lenny $ aptitude search ~o ... Actually no need for aptitude, $ apt-show-versions |grep No available version in archive$ will do the job. This is probably The solution.

Re: Frustration with randome number generator vuln and ssh

On Wed, Jun 04, 2008 at 02:37:38PM -0500, James Miller wrote: All I needed to do was run aptitude install libssl0.9.8=0.9.8c-4etch3 ... I have to admit, I _really_ need to learn aptitude, I'm kinda stuck in my ways using apt-get and dselect. I believe, that apt-get install package=version

OT: apt-get (was: Frustration with randome number generator vuln and ssh)

On Wed, Jun 04, 2008 at 10:24:53PM +0200, yosh wrote: Sorry for hijacking the thread :) If I choose install a package from stable and there is a newer copy in testing (which I'm using) apt-get will try to replace that package on the next apt-get upgrade. Is there any way to counteract