Re: amd64 running on Intel Celeron and Pentium?

On Sun, 17 Apr 2022, Friedhelm Waitzmann wrote: > > > You mean, that it is possible to run amd64 on my old hardware I had quite a lot of trouble mapping this a long time ago for intel-microcode. I ended up using several sources including, but not limited to: ark.intel.com, the processor

Re: Intel Microcode updates

On Sun, 23 Jun 2019, Elmar Stellnberger wrote: > As I read from the latest comments the microcode updates for Core 2 systems > are officially shipped by Intel via the internet though Intel denies this in Maybe you should fetch the Intel official release yourself and check it out yourself. --

Re: Intel Microcode updates

m 16:52 schrieb Henrique de Moraes Holschuh: > > (BCC'd to #929073 to avoid dragging the BTS into this thread). > > > > On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote: > > > Russell Coker schrieb: > > > > Should it be regarded as a bug in the intel-microcode pac

Re: Intel Microcode updates

(BCC'd to #929073 to avoid dragging the BTS into this thread). On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote: > Russell Coker schrieb: > > Should it be regarded as a bug in the intel-microcode package that it > > doesn't > > have this update that is "easy enough to source"? Or do you mean

Re: Intel Microcode updates

On Mon, 10 Jun 2019, Russell Coker wrote: > model name : Intel(R) Core(TM)2 Quad CPUQ9505 @ 2.83GHz > > On a system with the above CPU running Debian/Testing I get the following > results from the spectre-meltdown-checker script. Is this a bug in the intel- > microcode package that

Re: bind9: CVE-2018-5743

On Thu, 09 May 2019, Markus Wollny wrote: > Is there an ETA on the fix for this bind9 vulnerability to be > available for Debian Stretch yet? It is already available. > https://security-tracker.debian.org/tracker/CVE-2018-5743 says that > the stable branch is still vulnerable (fixed in

Re: [SECURITY] [DSA 4187-1] linux security update

On Fri, 04 May 2018, Davide Prina wrote: > On 04/05/2018 04:06, Paul Wise wrote: > > On Thu, May 3, 2018 at 4:53 PM, richard lucassen wrote: > > > > > There is also an big increase in time before random is initialized: > > ... > > > One of the consequences is that openntpd (or a program like > >

Re: [SECURITY] [DSA 4078-1] linux security update

On Fri, 12 Jan 2018, Moritz Mühlenhoff wrote: > Frank Nord schrieb: > > Peaking at ubuntu: > > https://usn.ubuntu.com/usn/usn-3522-3/ > > "USN-3522-1 fixed a vulnerability in the Linux kernel to address > > Meltdown (CVE-2017-5754). Unfortunately, that update introduced >

Re: [SECURITY] [DSA 4078-1] linux security update

On Thu, 11 Jan 2018, Frank Nord wrote: > I've problems applying this on my mac mini (Intel(R) Core(TM) 2 Duo CPU, > P7550 @ 2.6 GHz). ... > 3.20170707.1~deb9u1 from stretch. What's the recommended > microcode-version for this kernel? The one you have is currently fine. Intel has not published

Re: Huge Intel CPU Bug Allegedly Causes Kernel Memory Vulnerability With Up To 30% Performance Hit

On Wed, 03 Jan 2018, Vincent Deffontaines wrote: > It is not fixable by microcode, and requires ugly patching from the kernel > layer. Other OSes such as Microsoft are concerned as well. Nobody but Intel knows whether it is fixable in microcode or not for a given processor family. And Intel has

Re: HTTPS enabled Debian Security repository

On Fri, 27 Oct 2017, Hans-Christoph Steiner wrote: > This idea that GPG signatures on the index files is enough has been > totally disproven. There was a bug in apt where Debian devices could be > exploited by feeding them crafted InRelease files: > >

Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252

On Sat, 17 Dec 2016, Hans-Christoph Steiner wrote: > One thing that would help a lot with future issues like this is to use > only encrypted connections in /etc/apt/sources.list. That can be either > HTTPS or a Tor Hidden Service .onion address. For in depth discussion > of this, see: You could

Re: Vulnerabilities rated medium or low risk may not be fixed by Debian security team, is that correct?

On Wed, Oct 19, 2016, at 20:32, Alexander Schreiber wrote: > On Wed, Oct 19, 2016 at 12:51:06PM -0200, Henrique de Moraes Holschuh > wrote: > > On Tue, Oct 18, 2016, at 18:21, Florian Weimer wrote: > > > Right. Debian kernel updates can only be applied with a reboot. If >

Re: Vulnerabilities rated medium or low risk may not be fixed by Debian security team, is that correct?

hese updates. Is this correct? Really? -- Henrique de Moraes Holschuh <h...@debian.org>

Re: [SECURITY] [DSA 3547-1] imagemagick security update

On Wed, Apr 13, 2016, at 02:32, Peter Palfrader wrote: > On Tue, 12 Apr 2016, Michael Stone wrote: > > > On Tue, Apr 12, 2016 at 08:56:35PM -0300, Henrique de Moraes Holschuh wrote: > > >Then, maybe we should consider a better way to deal with areas where you > > >ge

Re: [SECURITY] [DSA 3547-1] imagemagick security update

ld alleviate most of my worries over a single mirror being returned in the geo-ip RRSET for some areas of the Internet. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." --

Re: [SECURITY] [DSA 3547-1] imagemagick security update

On Wed, Apr 13, 2016, at 05:50, Julien Cristau wrote: > On Tue, Apr 12, 2016 at 20:29:21 -0300, Henrique de Moraes Holschuh > wrote: > > On Tue, Apr 12, 2016, at 16:37, Michael Stone wrote: > > > On Tue, Apr 12, 2016 at 04:19:20PM -0300, Henrique de Moraes Holschuh > >

Re: [SECURITY] [DSA 3547-1] imagemagick security update

On Tue, Apr 12, 2016, at 16:47, Peter Palfrader wrote: > On Tue, 12 Apr 2016, Henrique de Moraes Holschuh wrote: > > > We list several mirrors carrying debian security updates in > > https://www.debian.org/mirror/list-full > > I think we shouldn't. Well, we do, regardl

Re: [SECURITY] [DSA 3547-1] imagemagick security update

On Tue, Apr 12, 2016, at 16:37, Michael Stone wrote: > On Tue, Apr 12, 2016 at 04:19:20PM -0300, Henrique de Moraes Holschuh > wrote: > >We don't disclose which mirrors are members of the security.debian.org > >pool anywhere (that I could find), so we are currently hiding ev

Re: [SECURITY] [DSA 3547-1] imagemagick security update

On Tue, Apr 12, 2016, at 14:32, Peter Palfrader wrote: > On Tue, 12 Apr 2016, Henrique de Moraes Holschuh wrote: > > On Tue, Apr 12, 2016, at 14:06, Adam D. Barratt wrote: > > > Judging from your e-mail address, I'm going to assume that the answer is > > > that s

Re: [SECURITY] [DSA 3547-1] imagemagick security update

The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>

ANNOUNCEMENT: AMD processor microcode security update

ts.org/oss-sec/2016/q1/450 http://www.theregister.co.uk/2016/03/06/amd_microcode_6000836_fix/ https://www.reddit.com/r/linux/comments/47s8a8/new_amd_microcode_vulnerability_from_unprivileged/ -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>

Re: [SECURITY] [DSA 3224-1] libx11 security update

of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org

Re: [SECURITY] [DSA 3121-1] file security update

On Fri, 09 Jan 2015, Christoph Biedl wrote: Henrique de Moraes Holschuh wrote... I do have a private backport of file/5.21+15, but it is a quick hack job that dropped multiarch and build-profile support to ease backporting. If someone has a better backport that preserves multiarch support

Re: [SECURITY] [DSA 3121-1] file security update

On Thu, 08 Jan 2015, Moritz Muehlenhoff wrote: Multiple security issues have been found in file, a tool/library to For the record, the file package currently in wheezy-backports is in dire need of a security update. It is in fact quite dangerous to run it if you have it installed together

Re: CVE-2014-6277, CVE-2014-6278

On Mon, 29 Sep 2014, john wrote: So I am confused. I think what I am reading here is that if you applied the latest patches to bash [3] you are not vulnerable to CVE-2014-6277. CVE-2014-6278. Running the test outlined on Icamtuf.blogspot.co.nz [4] seemed to confirm that. AFAIK, we are still

Re: Shellshock: Has CVE-2014-7186 and CVE-2014-7187 been addressed for debian

On Sat, 27 Sep 2014, john wrote: I was wondering if CVE-2014-7186 and CVE-2014-7187 been addressed yet for Debian. I note that Ubuntu pushed another patch addressing these earlier today. Yes, both are addressed by DSA-3035-1. AFAIK, these CVE numbers were not yet assigned at the time of the

Re: [SECURITY] [DSA 3032-1] bash security update

On Thu, 25 Sep 2014, Jan Wagner wrote: is there still work on CVE-2014-7169, as the fix for CVE-2014-6271 seems incomplete? Work on that is ongoing, AFAIK. AFAIK, exploits for CVE-2014-7169 are already public (one certainly worked here, with the CVE-2014-6271 patch applied), and there are

Re: [SECURITY] [DSA 3032-1] bash security update

On Thu, 25 Sep 2014, Henrique de Moraes Holschuh wrote: BTW: sudo is a viable local attack vector for this vulnerability. Sort of... turns out it has defenses, which are not immediately obvious to me how to bypass. -- One disk to rule them all, One disk to find them. One disk to bring them

Re: [SECURITY] [DSA 3027-1] libav security update

On Thu, 18 Sep 2014, Paul Wise wrote: On Thu, Sep 18, 2014 at 7:30 AM, Bruce Eason wrote: YIKES!! can i help? The Debian security team can always use some help finding, fixing and tracking security issues. Please read the following pages and join our IRC channel if you would like to

Re: Debian mirrors and MITM

On Fri, 30 May 2014, Erwan David wrote: Le 30/05/2014 21:30, Joey Hess a écrit : Alfie John wrote: Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list https://mirrors.kernel.org/debian is the only one I know of. It would be good

[Debian 6 Squeeze] ANNOUNCEMENT: Intel processor microcode security update

THIS ANNOUNCEMENT IS ONLY MEANINGFUL FOR PEOPLE USING DEBIAN 6 (SQUEEZE) ON COMPUTERS WITH INTEL PROCESSORS. IT DOES NOT APPLY TO THE MORE RECENT DEBIAN RELEASES. A new Intel microcode update is available for Debian 6 (codename Squeeze). This microcode update is considered a security update.

Re: L2TP/IPSec on Mac OSX stop working after openswan upgrade [with patches]

On Tue, 29 Apr 2014, Liu DongMiao wrote: After checking the patch, I found the it's CVE-2013-6466.patch, it removes the compatible code for mac os x and ios, which use a bad draft. Now, I have fixed this, and test on mac os x and ios. However, I didn't test on other platform, such as linux,

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

On Sun, 15 Dec 2013, Robert Millan wrote: Backporting the fix to these kernels might be a good idea, probably best routed through an stable update upload (and not a security upload). This might be a bit complicated due to significant changes in internal APIs. I'm also unsure if the yarrow

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

On Sat, 14 Dec 2013, Steven Chamberlain wrote: On 14/12/13 01:08, Henrique de Moraes Holschuh wrote: Yeah, I think Linux went through similar blindness braindamage sometime ago, but blind trust on rdrand has been fixed for a long time now, and it never trusted any of the other HRNGs

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

On Sat, 14 Dec 2013, Robert Millan wrote: we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random. Yeah, I think Linux went through similar blindness braindamage sometime ago, but blind trust on rdrand

Re: MIT discovered issue with gcc

On Sat, 23 Nov 2013, Michael Tautschnig wrote: This should be taken with a grain of salt. (I'm doing research in the area of automated software analysis myself.) It clearly is a well-written paper with a nice tool. Yet unstable code results from code that would otherwise be considered bogus

Re: Debian APT Key Revocation Procedure

On Sun, 03 Nov 2013, Stephen Gran wrote: This one time, at band camp, Henrique de Moraes Holschuh said: For a more precise answer, please ask the debian-admin ML. Why? DSA has nothing to do with this. Hmm, come to think of it you're correct that they're not the best team to ask about

Re: Debian APT Key Revocation Procedure

On Thu, 31 Oct 2013, adrelanos wrote: But what could you do with the revocation certificate? Only manually spread the news and ask users to obtain the revocation certificate? We would widely publish that information, that's a given. But it is not the only way to publish the revocation

ANNOUNCEMENT: Intel processor microcode security update (20130906)

A new Intel microcode update (dated 20130906) is available on unstable, testing and also on wheezy-backports. A Debian Stable update (through stable-proposed-updates) has been requested, but it may take some time for it to be approved. If you cannot wait, please use the wheezy-backports packages

Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)

On Sun, 08 Sep 2013, Henrik Ahlgren wrote: or synaptic to look for new tools, right? Or can we just enable those two repositories long enough to load Henrique's tool and the microcode updates, then disable them again? Why do you feel that you even need to ask? You are free to handle the

Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)

On Sun, 08 Sep 2013, Joel Rees wrote: I was hoping that AMD was not going to have the license and non-visibility issue that plagues the Intel processor microcode updates. But I find this original announcement from when Henrique made the updater tool available:

ANNOUNCEMENT: Intel processor microcode security update

THIS ANNOUNCEMENT IS ONLY RELEVANT TO SYSTEMS THAT HAVE INTEL MICROPROCESSORS. Intel has released a microcode update that fixes at least one severe fault on every desktop and mobile Intel Core i* and server Intel Xeon system processor models since (and including) the 1st generation Core-i3/i5/i7

Re: ANNOUNCEMENT: Intel processor microcode security update

On Tue, 03 Sep 2013, Paul Wise wrote: On Tue, Sep 3, 2013 at 2:05 PM, Henrique de Moraes Holschuh wrote: THIS ANNOUNCEMENT IS ONLY RELEVANT TO SYSTEMS THAT HAVE INTEL MICROPROCESSORS. Should this have been sent to debian-security-announce instead? Well, the security team declined to have

Re: ANNOUNCEMENT: Intel processor microcode security update

On Tue, 03 Sep 2013, Henrique de Moraes Holschuh wrote: Alternatively, you can install the packages manually. To get the updated packages directly, please install the current intel-microcode and iucode-tool packages normally, then download and install the updated intel-microcode package

Re: Compromising Debian Repositories

On Sat, 03 Aug 2013, Volker Birk wrote: On Sat, Aug 03, 2013 at 08:46:53PM +1000, Aníbal Monsalve Salazar wrote: On Sat, Aug 03, 2013 at 12:17:06PM +0200, Volker Birk wrote: Not to mention the build tool chains. It reminds me of Ken Thompson's article Reflections on Trusting Trust. Yes,

Re: how to fix rootkit?

On Thu, 09 Feb 2012, Russell Coker wrote: There are devices which use firewire to directly access system RAM. It is also possible to design a PCI/PCIe card which does bus-mastering on external control to dump RAM contents. I've seen a live demonstration of the use of In both cases, an

Re: World writable pid and lock files.

On Wed, 11 May 2011, Mike Mestnik wrote: On 05/11/11 01:37, helpermn wrote: On Tue, 10 May 2011, Henrique de Moraes Holschuh h...@debian.org wrote: On Tue, 10 May 2011, helpermn wrote: I imagine why files listed below have 666 file mode bits set: /var/run/checkers.pid /var/run/vrrp.pid

Re: World writable pid and lock files.

On Tue, 10 May 2011, helpermn wrote: I imagine why files listed below have 666 file mode bits set: /var/run/checkers.pid /var/run/vrrp.pid /var/run/keepalived.pid /var/run/starter.pid /var/lock/subsys/ipsec Files are created during startup of ipsec (pluto) and keepalived deamons. I

Re: Squeeze vulnerable to CVE-2010-2943 (xfs+NFS unlinked inode access)

On Thu, 17 Feb 2011, dann frazier wrote: http://security-tracker.debian.org/tracker/CVE-2010-2943 It is supposed to be vulnerable. I've backported a fix for this, but it was too late to make the initial release of squeeze. The fix is queued for the first update to squeeze, see:

Squeeze vulnerable to CVE-2010-2943 (xfs+NFS unlinked inode access)

On Wed, 16 Feb 2011, Pascal Hambourg wrote: Johan Grönqvist a écrit : 2011-02-15 22:46, Kelly Dean skrev: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-2943 was published Sept 30, 2010, and says that Linux 2.6.32.5 is vulnerable. Squeeze uses 2.6.32-5, built on Jan 12, 2011. Is

Re: some feedback about security from the user's point of view

On Mon, 24 Jan 2011, René Mayrhofer wrote: Therefore, I strongly suggest to move away from all uses of MD5 and use SHA-2 (=256) instead (SHA1 already makes the crypto community No. Let's stick to SHA2-256, please. There are some doubts about how well sha2-512 holds, it may actually be weaker

Re: Question related to FDE (Full Disk Encryption) solution under Linux Debian Lenny

On Mon, 24 Jan 2011, Thomas Nguyen Van wrote: Our company needs to encrypt hard drives on our machines running under Linux Debian Lenny. If you're serious about this, get a real server (HP, IBM, Dell...) with proper TPM hardware and Linux support. Then, you'll need to do the (not that easy)

Re: Any Account Logs In With Any Password

On Mon, 25 Oct 2010, Michael Loftis wrote: checks prior to this indicate a soft success. If you remove authentication from your system, its expected that any attempt to access will pass, barring and specific denial. If I remove authentication from my system, I expect it to tell me to get

Re: Any Account Logs In With Any Password

On Wed, 27 Oct 2010, Jordon Bedwell wrote: On 10/27/2010 04:05 PM, Henrique de Moraes Holschuh wrote: On Mon, 25 Oct 2010, Michael Loftis wrote: checks prior to this indicate a soft success. If you remove authentication from your system, its expected that any attempt to access will pass

Re: CVE-2009-3555 not addressed in OpenSSL

On Wed, 29 Sep 2010, Marsh Ray wrote: These five bytes will mean the world to some server admin somewhere, who's boss is questioning his judgment for installing Debian everywhere and now users are starting to report strange warnings in their browsers. Very well. Do we have something from

Re: Cleanup portsentry's iptables rules (WAS: HEAD's UP: possible 0day SSH exploit in the wild)

On Mon, 13 Jul 2009, Maik Holtkamp wrote: I decided to follow this and on the weekend iptables blocked about 70 IPs. I am afraid that after some time the box will be DOSed by the crowded INPUT chain. The only _real_ fix for that is to use IPSET (patch for netfilter) to deal with IPv4, and

HEAD's UP: possible 0day SSH exploit in the wild

As usual, you may want to either raise shields (i.e. disable/restrict access to the ssh service), or pay extra attention to what is happening on your SSH inbound gateways... http://lwn.net/Articles/340360/ http://isc.sans.org/diary.html?storyid=6742

Re: Debian suggestion on File Deletion

On Mon, 01 Jun 2009, X-No Archive wrote: XXMETAXX NAME=XOBOTS CONTENT=NOXNDEX x-XX-XXchive: yes (defanged just in case). What would exactly this accomplish? It will go to the WWW mail archives, but would it contaminate the rest of the pages there and hose spidering for the WWW mail archives?

Re: Debian suggestion on File Deletion

On Mon, 01 Jun 2009, X-No Archive wrote: Debian should upgrade its listings software to more modern ones such as google or nabble. I recall we used to honour X-no-archive in the mail *HEADER*, but that was a _LONG_ time ago, I don't know if we still do. -- One disk to rule them all, One

Re: Why is su preserving the environment?

On Sat, 24 Jan 2009, Arthur de Jong wrote: On Sat, 2009-01-24 at 11:07 +0100, Josselin Mouette wrote: The question is whether we can consider safe to pass authentication tokens as environment variables. Either we do, and we fix applications that pass environment where they shouldn???t.

Re: What to do about SSH brute force attempts?

On Thu, 21 Aug 2008, Michael Tautschnig wrote: * use a Firewall to prevent other IP address to connect to your ssh service. restrict just to yours (iptables script can be easy to find on the web) Well, I should have added that my hosts must be world-wide accessible using password-based

Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver

On Tue, 08 Jul 2008, Florian Weimer wrote: 1. Install a local BIND 9 resoler on the host, possibly in forward-only mode. BIND 9 will then use source port randomization when sending queries over the network. (Other caching resolvers can be used instead.) 2. Rely on IP address spoofing

Re: [SECURITY] [DSA 1571-1] vulnerability of past SSH/SSL sessions

On Wed, 14 May 2008, Micah Anderson wrote: authenticity of the server. In other words, ssh sessions are not compromised just because an adversary has the host keys (unless a MITM is setup, in which case you need bot the host key and the authentication key to perform a mitm attack). Ok. But I

Re: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator

On Wed, 14 May 2008, Florian Weimer wrote: I agree it would be neat if someone with a powerful machine could generate all possible keys. I don't know how long that would take however... It's not so much a time issue, is a question of storage (or getting that data to the OpenSSH

Re: Why not have firewall rules by default?

On Wed, 23 Jan 2008, Rolf Kutz wrote: On 23/01/08 08:29 -0700, Michael Loftis wrote: It's better to leave the service disabled, or even better, completely uninstalled from a security standpoint, and from a DoS standpoint as well. The Linux kernel isn't very efficient at processing firewall

Re: Why not have firewall rules by default?

On Fri, 25 Jan 2008, Török Edwin wrote: If it is 2.6, I suggest you to contact the netfilter mailing list [1], and show them your firewall rules, What makes you think they don't know about this? It is a design detail of the way netfilter is implemented, and the two methods of acceleration I

Re: Time to replace MD5?

On Wed, 13 Jun 2007, Florian Weimer wrote: On Tue, 12 Jun 2007, Touko Korpela wrote: Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? When combined with size information Size information

Re: Time to replace MD5?

On Tue, 12 Jun 2007, Touko Korpela wrote: Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? When combined with size information AND the fact that it needs to be a valid .deb archive, they are probably

Re: debian.org DNSs allow unrestricted zone transfers

On Tue, 15 May 2007, Abel Martín wrote: I thought zone transfers should only be possible between DNSs which have records for the same domain, so why are debian.org DNSs (raff, Only if you have a reason to hide who is in your domain. possibility of suffering DoS attacks (it serves 254

Re: Remote Root In Nvidia xserver Driver

On Wed, 18 Oct 2006, Sam Morris wrote: sshing to a compromised machine with X forwarding enabled is already a big enough problem without adding root exploits. Don't ssh with X forwarding to an untrusted machine. Ever. The point is that I may trust the machine, it may have been

Re: When are security updates effective?

On Thu, 31 Aug 2006, Sam Morris wrote: You can check with # lsof +L1 It will show you open Files that have been unlinked. If any of those are part of the upgraded packages, you restart that process. Note that this has been broken since at most Linux 2.6.8. Relying on it may

Re: su - and su - what is the real difference?

On Fri, 28 Jul 2006, LeVA wrote: What is the difference (I mean in the real world) between running `su` (getting a non-login shell) and `su -` (getting a login shell). Is The same that using /bin/su - gains you: a bit more of defence against someone doing nasty things to your environment.

Re: How to prevent daemons from ever being started?

On Mon, 15 May 2006, Emanuele Rocca wrote: I don't have an answer for the don't start upon new install problem, though. I do. invoke-rc.d support is *mandatory* now in Debian, which means that for Sid and Etch you can write a policy-rc.d file that forbids starting new daemons before you

Re: avahi-daemon

On Fri, 03 Mar 2006, Loïc Minier wrote: This is a desktop machine, it should permit sharing of files on your local network. DNS servers have their port 53 open to respond to name In what planet do you live? Desktop machines are plugged to extremely hostile networks all the time (think cable

Re: avahi-daemon

On Fri, 03 Mar 2006, Michael Stone wrote: On Fri, Mar 03, 2006 at 10:47:56AM -0300, Henrique de Moraes Holschuh wrote: Mounting malicious filesystems automatically (vfat can't be one AFAIK, but it won't bork if you tell it to be nosuid, nodev either) is never a feature, it is a security hole

Re: avahi-daemon

On Fri, 03 Mar 2006, Loïc Minier wrote: If music sharing is a questionable feature to you, you don't need to discuss this further, you're obviously the security guy, talking in debian-security@ of stuff he doesn't want to support security-wise, and You are *not allowed* to support security

Re: avahi-daemon

On Fri, 03 Mar 2006, Loïc Minier wrote: On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: True. But that requires a broken kernel, which we patch regularly as a security procedure anyway. Mounting removable filesystems suid,dev allow a lot more damage *by design* in the standard

Re: avahi-daemon

On Fri, 03 Mar 2006, Loïc Minier wrote: On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: Well, no: that's the opposite of plug'n'play. See, if you're USB stick contains a malicious vfat file system, it gets automatically mounted nevertheless. It's a feature. Not in my

Re: avahi-daemon

On Fri, 03 Mar 2006, Loïc Minier wrote: proposed multiple options in other posts, all of them ignored. People *not* trying for a middle-ground solution are those claiming an open port by default is unacceptable, no matter what. You will notice I didn't propose you disable open ports by

Re: Using multicast for security updates

On Thu, 23 Feb 2006, Neal Murphy wrote: On Thursday 23 February 2006 17:05, Michael Loftis wrote: Good idea except this requires large scale rollout of mutlicast, which AFAIK, hasn't happened. I thought it had progressed further than being a curiosity. Is its current scale enough to make

Re: avahi-daemon

On Wed, 22 Feb 2006, aliban wrote: On debian testing the rhythmbox suggested to install the avahi-daemon that listens on all interfaces by default. That's on par with the avahi-daemon's idea of how things should happen, and it makes sense. Not that I'd want that active in my LAN anyway. If

Re: Security implications of allowing init to re-exec from another path

On Wed, 04 Jan 2006, Thomas Hood wrote: In #345741 the submitter has requested that /sbin/init be enhanced such that it can be re-executed from another path. The idea is that telinit -e INIT_PROG=/path/to/other/init could be done prior to telinit u. Reasons for introducing this feature are

Re: PMASA-2005-6 when register_globals = on

On Tue, 15 Nov 2005, Steve Kemp wrote: On Tue, Nov 15, 2005 at 05:54:32PM +0100, Piotr Roszatycki wrote: http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-6 reports that sarge's phpmyadmin package has a security flaw which is occured only if register_globals = on

Re: CAN to CVE: changing changelogs?

On Sat, 29 Oct 2005, Thomas Bushnell BSG wrote: Because it omits information, crucially, when a particular fact was learned. Why obscure information deliberately? That is my whole point of contention. Not that I'd advocate going over the changelog to add and update CAN and CVE data, as

Re: CAN to CVE: changing changelogs?

On Fri, 28 Oct 2005, Thomas Bushnell BSG wrote: Frans Pop [EMAIL PROTECTED] writes: On Thursday 27 October 2005 23:34, Henrique de Moraes Holschuh wrote: To me it is a technical matter, as the changelogs are a tool for a technical job. To me, changelogs are primarily a way of informing

Re: CAN to CVE: changing changelogs?

On Fri, 28 Oct 2005, Thomas Bushnell BSG wrote: Joey Hess [EMAIL PROTECTED] writes: One thing that this bug illustrates pretty well that is quite annoying when trying to determine what version of a package actually fixed a security hole, is new upstream releases that are listed in the

Re: CAN to CVE: changing changelogs?

On Thu, 27 Oct 2005, Horms wrote: On Wed, Oct 26, 2005 at 11:32:15AM +0200, Thijs Kinkhorst wrote: Hello people, As many of you are probably aware, CVE has changed the naming of their id's: the temporary CAN- prefix has been dropped and an id is now always of the form CVE--.

Re: CAN to CVE: changing changelogs?

On Thu, 27 Oct 2005, Horms wrote: I believe that changelogs should never be changed restrospectively. Why not? Technical reasons only, please. Fixing changelogs so that they are more useful in the future is common in Debian. These are slight edits, always, not entry suppresion or

Re: CAN to CVE: changing changelogs?

On Thu, 27 Oct 2005, Thomas Bushnell BSG wrote: Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: But at least we know that this subthread can end right here, right now. It is useless to discuss beliefs that exist without a technical backing, and I won't waste my time with it. Do

Re: CAN to CVE: changing changelogs?

On Thu, 27 Oct 2005, Joey Hess wrote: Henrique de Moraes Holschuh wrote: 3. The security team's work is helped by adding the CVE information to the proper changelog entry, to the point that they have requested everyone to do so. This requires editing past changelog

Re: CAN to CVE: changing changelogs?

On Thu, 27 Oct 2005, Henrique de Moraes Holschuh wrote: On Thu, 27 Oct 2005, Joey Hess wrote: Henrique de Moraes Holschuh wrote: 3. The security team's work is helped by adding the CVE information to the proper changelog entry, to the point that they have requested everyone

Re: CAN to CVE: changing changelogs?

On Thu, 27 Oct 2005, Michael Stone wrote: You know, you could have just not posted in the first place. Posting a personal opinion about someone else's personal preference and then ranting about people wasting your time questioning your personal preferences is just flat out stupid. We all make

Re: CAN to CVE: changing changelogs?

On Thu, 27 Oct 2005, Frans Pop wrote: On Thursday 27 October 2005 22:30, Henrique de Moraes Holschuh wrote: When dealing with Debian matters of a technical nature, yes. When dealing with matters outside Debian, or of a non-technical nature, I may decide to not take such an instance

Re: SELinux

On Wed, 21 Sep 2005, Arvind Autar wrote: is no loss of functionality, why hasn't debian implented SELinux as default? It is not that simple. We are doing it slowly. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the

Re: Bad press again...

On Sat, 27 Aug 2005, Florian Weimer wrote: * martin f. krafft: I think Alvin was alluding to how it *should* be solved. As in: we should have more than one security server, globally spaced. security.debian.org already is a Single Point of Ownership. I don't think we need multiple ones,

Re: Bad press again...

On Sat, 27 Aug 2005, Florian Weimer wrote: I don't think so. Joey seems to be satisfied with this situation, and apart from unanswered email messages to [EMAIL PROTECTED], there are few complaints, AFAIK. The email part is very unfortunate indeed, but it probably doesn't warrant drastic

Re: Bad press again...

Hi martin! On Sat, 27 Aug 2005, martin f krafft wrote: also sprach Henrique de Moraes Holschuh [EMAIL PROTECTED] [2005.08.27.1540 +0200]: security.debian.org already is a Single Point of Ownership. I don't think we need multiple ones, so this is definitely a post-etch thing

Re: Bad press again...

On Sat, 27 Aug 2005, Henrique de Moraes Holschuh wrote: For this to work, you need a master s.d.o mirror, and automatic signing (so that you can keep the timestamping as low as a few hours). This gives you a mirror network, with the same single owning point of failure we have right now. Add

Re: Bad press again...

On Sat, 27 Aug 2005, Florian Weimer wrote: * Henrique de Moraes Holschuh: On Sat, 27 Aug 2005, Florian Weimer wrote: I don't think so. Joey seems to be satisfied with this situation, and apart from unanswered email messages to [EMAIL PROTECTED], there are few complaints, AFAIK

  1   2   >