Re: Embarrassing security bug in systemd

On 12/08/2017 05:12 PM, Cindy-Sue Causey wrote: Something I did *not* understand when I saw it in operation was why a password was needed at the terminal but not from within the GUI's "Applications > Log Out" menu path. Thank you Cindy, now I don't have to point out the obvious! :) Ric --

Re: Embarrassing security bug in systemd

On Sat 09 Dec 2017 at 10:12:16 +, Joe wrote: > On Fri, 8 Dec 2017 23:56:44 + > Brian wrote: > > > On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote: > > > > > On Fri, 8 Dec 2017 17:12:18 -0500 > > > Cindy-Sue Causey wrote: > > > > > > >

Re: Embarrassing security bug in systemd

On Fri, 8 Dec 2017 23:56:44 + Brian wrote: > On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote: > > > On Fri, 8 Dec 2017 17:12:18 -0500 > > Cindy-Sue Causey wrote: > > > > > > > > I do remember having to give a password, but I don't

Re: Embarrassing security bug in systemd

On Sat 09 Dec 2017 at 07:52:56 +, Jonathan Dowland wrote: > On Fri, Dec 08, 2017 at 07:57:03PM +, Brian wrote: > > > That's a good point. > > > > Not really. systemd doesn't stop providing a single place to define a > > consistent policy because a set of users do not use it. > > That's

Re: Embarrassing security bug in systemd

On Sat, 09 Dec 2017 01:46:59 + Mark Fletcher wrote: > The OP has never been seen again since the original post. Just > sayin’... > > Because he accidentally discovered a new feature, thought it was a bug, and was immediately corrected. End of story. We've been

Re: Embarrassing security bug in systemd

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 08, 2017 at 05:04:51PM -0600, John Hasler wrote: > tomas writes: > > Not a fan of systemd here (have outed myself this way clearly enough, > > I think), but systemd is pretty well documented, for sure. > > Is the Debian default

Re: Embarrassing security bug in systemd

On Sat, Dec 09, 2017 at 01:30:17AM +, Glenn English wrote: Even if there's an error in the release note? Less than optimal way to run a train. Errors and omissions are different things. I'm not responsible for release notes but I suspect if there was something that was glaringly false, it

Re: Embarrassing security bug in systemd

On Fri, Dec 08, 2017 at 03:31:54PM -0500, Gene Heskett wrote: On Friday 08 December 2017 14:26:41 Jonathan Dowland wrote: No objection there, and I agree that the release notes should probably have covered the policy changes. That ship has now sailed unfortunately. So now, no effort will ever

Re: Embarrassing security bug in systemd

On Fri, Dec 08, 2017 at 07:57:03PM +, Brian wrote: That's a good point. Not really. systemd doesn't stop providing a single place to define a consistent policy because a set of users do not use it. That's not the point I thought was good: the point is, in Debian, systemd is optional. As

Re: Embarrassing security bug in systemd

Glenn writes: > Even if there's an error in the release note? Less than optimal way to > run a train. You can't retroactively fix the release notes: they are part of the already released release. All you can do is publish an errata and correct the error in the next point release. -- John Hasler

Re: Embarrassing security bug in systemd

On 12/07/2017 02:31 AM, Jonathan Dowland wrote: On Thu, Dec 07, 2017 at 10:02:56AM +, Tixy wrote: I'm running Jessie (with systemd running but booting with sysvinit) and trying to execute halt/poweroff/reboot/shutdown from a terminal without root privileges gives an error saying I must be

Re: Embarrassing security bug in systemd

The OP has never been seen again since the original post. Just sayin’... On Sat, Dec 9, 2017 at 9:39 Menelaos Maglis wrote: > Joe writes: > > > I think there's a case for asking which way to set it during an expert > > install or during the upgrade that

Re: Embarrassing security bug in systemd

On Fri, Dec 8, 2017 at 9:07 PM, John Hasler wrote: > Gene Heskitt writes: >> So now, no effort will ever be made to fix the man pages. Hell of a >> way to run a train. > > That doesn't follow. The release note are specific to the release and > thus obviously cannot be

Re: Embarrassing security bug in systemd

Joe writes: > I think there's a case for asking which way to set it during an expert > install or during the upgrade that reversed the default setting. I think it is policy not to touch locally changed configuration during upgrades. Usually packages ask what to do and/or

Re: Embarrassing security bug in systemd

On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote: > On Fri, 8 Dec 2017 17:12:18 -0500 > Cindy-Sue Causey wrote: > > > > > I do remember having to give a password, but I don't remember how long > > ago now. And I have too much open right now to test drive whether mine >

Re: Embarrassing security bug in systemd

tomas writes: > Not a fan of systemd here (have outed myself this way clearly enough, > I think), but systemd is pretty well documented, for sure. Is the Debian default configuration of Systemd also well documented? -- John Hasler jhas...@newsguy.com Elmwood, WI USA

Re: Embarrassing security bug in systemd

h changelogs to look for real gotchas that affect me (not really many of them) and I don't recall seeing a warning about this. And it *should* have been a warning, not just a tiny footnote, because it's a [small] security measure being turned off by default. That shouldn't happen during an upgrade

Re: Embarrassing security bug in systemd

On 12/7/17, Dave Sherohman wrote: > On Thu, Dec 07, 2017 at 11:26:45AM +1300, Ben Caradoc-Davies wrote: >> Special privileges have been granted to console users for as long as I >> can >> remember, long before systemd, because they have physical access to the >> machine.

Re: Embarrassing security bug in systemd

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 08, 2017 at 03:29:20PM -0500, Gene Heskett wrote: [...] > Which until now I have never seen its supposed advantages touted. Maybe I > don't subscribe to the right lists? Hey, to each her/his own... > rant mode on! > > Couldn't a lot

Re: Embarrassing security bug in systemd

Gene Heskitt writes: > So now, no effort will ever be made to fix the man pages. Hell of a > way to run a train. That doesn't follow. The release note are specific to the release and thus obviously cannot be fixed. The man pages can be fixed in any future release of the subject packages. File

Re: Embarrassing security bug in systemd

On Friday 08 December 2017 14:26:41 Jonathan Dowland wrote: > On Fri, Dec 08, 2017 at 07:09:06PM +0100, Menelaos Maglis wrote: > >>> > Basically, it was a completely inconsistent mess before systemd. > >>> > Now you at least have a central place where you can configure > >>> > your system

Re: Embarrassing security bug in systemd

On Friday 08 December 2017 13:09:06 Menelaos Maglis wrote: > >> > Basically, it was a completely inconsistent mess before systemd. > >> > Now you at least have a central place where you can configure > >> > your system behaviour. > > > > In the past, we had *no consistency*: inittab had one

Re: Embarrassing security bug in systemd

to...@tuxteam.de wrote: > Now watch all the old skoolers dashing out of their little caves and > waving their fists at something which could be read as a provocation > (I'm myself one of those, just look a bit upthread :) > It is not about old or new, but about known and unknown. Unkown exposes

Re: Embarrassing security bug in systemd

On Fri 08 Dec 2017 at 19:26:41 +, Jonathan Dowland wrote: > On Fri, Dec 08, 2017 at 07:09:06PM +0100, Menelaos Maglis wrote: > > > > > Basically, it was a completely inconsistent mess before systemd. > > > > > Now you at least have a central place where you can configure your > > > > > system

Re: Embarrassing security bug in systemd

On Fri, Dec 08, 2017 at 07:09:06PM +0100, Menelaos Maglis wrote: > Basically, it was a completely inconsistent mess before systemd. > Now you at least have a central place where you can configure your > system behaviour. In the past, we had *no consistency*: inittab had one thing, display

Re: Embarrassing security bug in systemd

Roberto C. Sánchez wrote: > That is really the problem that I have with this while issue that was > brought up.  I get that it is a "sensible" default to allow users on the > console (TTY or via DM) permission to reboot the machine.  However, when > an admin has configured the system to disallow

Re: Embarrassing security bug in systemd

>> > Basically, it was a completely inconsistent mess before systemd. >> > Now you at least have a central place where you can configure your >> > system behaviour. > In the past, we had *no consistency*: inittab had one thing, display > managers another, ACPI scripts another...if you wanted a

Re: Embarrassing security bug in systemd

>> > Basically, it was a completely inconsistent mess before systemd. >> > Now you at least have a central place where you can configure your >> > system behaviour. > In the past, we had *no consistency*: inittab had one thing, display > managers another, ACPI scripts another...if you wanted a

Re: Embarrassing security bug in systemd

On 2017-12-08, Jonathan Dowland wrote: > On Fri, 2017-12-08 at 12:17 +0100, deloptes wrote: >> Michael Biebl wrote: >> >> > Basically, it was a completely inconsistent mess before systemd. >> > Now you at least have a central place where you can configure your >> > system

Re: Embarrassing security bug in systemd

On Fri, 2017-12-08 at 12:17 +0100, deloptes wrote: > Michael Biebl wrote: > > > Basically, it was a completely inconsistent mess before systemd. > > Now you at least have a central place where you can configure your > > system behaviour. > > This is your opinion - if you can not understand the

Re: Embarrassing security bug in systemd

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 08, 2017 at 12:17:16PM +0100, deloptes wrote: > Michael Biebl wrote: > > > Basically, it was a completely inconsistent mess before systemd. [...] > This is your opinion - if you can not understand the "mess" it is a mess. > For most

Re: Embarrassing security bug in systemd

On Fri, Dec 08, 2017 at 10:17:36AM +0100, Menelaos Maglis wrote: > > It is an improvement to have a consistent (central) way to configure > this behavior. > > It is probably a "good thing" to allow users with physical access to > reboot/shutdown a desktop/laptop system. > > It is probably not a

Re: Embarrassing security bug in systemd

Michael Biebl wrote: > Basically, it was a completely inconsistent mess before systemd. > Now you at least have a central place where you can configure your > system behaviour. This is your opinion - if you can not understand the "mess" it is a mess. For most of us who dislike systemd your same

Re: Embarrassing security bug in systemd

>>> I wonder how can such a severe bug make it into a Debian stable >>> distribution? And is this just an insane default setting on Debian's >>> side or is it yet another instance of brain-dead systemd behavior? >> >> Maybe I am just a brain-dead loony, but personally I prefer to be able to >>

Re: Embarrassing security bug in systemd

On Thu, Dec 07, 2017 at 09:37:25AM -0500, Roberto C. Sánchez wrote: > On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote: > > > > I no longer have any non-systemd machines handy to verify this on, but > > my memory is that I have *always* been able to use halt/poweroff/reboot > >

Re: Embarrassing security bug in systemd

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Dec 07, 2017 at 08:03:47PM +0100, Michael Biebl wrote: [...] > Basically, it was a completely inconsistent mess before systemd. > Now you at least have a central place where you can configure your > system behaviour. Hey, I'm "before

Re: Embarrassing security bug in systemd

Am 07.12.2017 um 15:37 schrieb Roberto C. Sánchez: > On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote: >> >> I no longer have any non-systemd machines handy to verify this on, but >> my memory is that I have *always* been able to use halt/poweroff/reboot >> commands from the console

Re: Embarrassing security bug in systemd

On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote: > > I no longer have any non-systemd machines handy to verify this on, but > my memory is that I have *always* been able to use halt/poweroff/reboot > commands from the console without requiring sudo or entering a password, > and

Re: Embarrassing security bug in systemd

On Thu, Dec 07, 2017 at 10:02:56AM +, Tixy wrote: I'm running Jessie (with systemd running but booting with sysvinit) and trying to execute halt/poweroff/reboot/shutdown from a terminal without root privileges gives an error saying I must be superuser. Which has always been my experience in

Re: Embarrassing security bug in systemd

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote: > On Thu, Dec 07, 2017 at 11:26:45AM +1300, Ben Caradoc-Davies wrote: > > Special privileges have been granted to console users for as long as I can > > remember, long before systemd,

Re: Embarrassing security bug in systemd

On Thu, 2017-12-07 at 03:03 -0600, Dave Sherohman wrote: > > I no longer have any non-systemd machines handy to verify this on, but > my memory is that I have *always* been able to use halt/poweroff/reboot > commands from the console without requiring sudo or entering a password, > and I've been

Re: Embarrassing security bug in systemd

On Thu, Dec 07, 2017 at 11:26:45AM +1300, Ben Caradoc-Davies wrote: > Special privileges have been granted to console users for as long as I can > remember, long before systemd, because they have physical access to the > machine. Console users typically are also permitted to mount, unmount, and >

Re: Embarrassing security bug in systemd

On Wed, 6 Dec 2017 17:35:18 -0500 Michael Stone wrote: > On Wed, Dec 06, 2017 at 10:52:17PM +0100, Urs Thuermann wrote: > >Yesterday, my 10 years old son logged into my laptop running Debian > >jessie using his account, and curiously asked if he is allowed to try > >the

Re: Embarrassing security bug in systemd

On יום רביעי, 6 בדצמבר 2017 22:52:17 IST Urs Thuermann wrote: > Yesterday, my 10 years old son logged into my laptop running Debian > jessie using his account, and curiously asked if he is allowed to try > the /sbin/reboot command. Knowing I have a Linux system as opposed to > some crappy Win

Re: Embarrassing security bug in systemd

On Wednesday, 6 Dec 2017 at 22:52, Urs Thuermann wrote: > Yesterday, my 10 years old son logged into my laptop running Debian > jessie using his account, and curiously asked if he is allowed to try > the /sbin/reboot command. Security issues etc. aside, I love the fact that your 10

Re: Embarrassing security bug in systemd

On Wednesday, 6 Dec 2017 at 20:21, Nicholas Geovanis wrote: > As a former system admin for a university's 370/158 (yes, in the > Jurassic), all I can say is, wow. That really wouldn't work in an > American university (big surprise there...). None of that stuff was > anywhere near a normal human

Re: Embarrassing security bug in systemd

Roberto C. Sánchez wrote: > Then I upgraded, got systemd and it turns out that > my configuration has been silently broken for a very long time. to prevent this, keep a list with your customizations and use it as check list after upgrade I also see nothing wrong when someone that could press

Re: Embarrassing security bug in systemd

nd > one-off site specific hacks. Having this functionality standardized in one > place is a net win for security, especially since there's also now a single > standarized way to change the privileges. > I don't necessarily disagree that having it centralized is a win. I do, however, t

Re: Embarrassing security bug in systemd

On Wed, Dec 06, 2017 at 10:48:11PM +, Brian wrote: > On Wed 06 Dec 2017 at 22:52:17 +0100, Urs Thuermann wrote: > > > Yesterday, my 10 years old son logged into my laptop running Debian > > jessie using his account, and curiously asked if he is allowed to try > > the /sbin/reboot command.

Re: Embarrassing security bug in systemd

On Thu, Dec 07, 2017 at 12:18:30PM +1300, Ben Caradoc-Davies wrote: > On 07/12/17 11:30, Roberto C. Sánchez wrote: > > I too consider this a rather serious bug. However, I do not see any > > evidence in the BTS [0] that such a bug has yet been reported against > > systemd. > > Not a bug. We can

Re: Embarrassing security bug in systemd

ff that doesn't belong there, has no function there. If we're going to deploy these machines, why can't the manufacturers get a real, solid clue about physical security of the hardware? If the mainframes could do it 35 years ago why can't it be done today with smaller, discrete servers? Answer: It can be, b

Re: Embarrassing security bug in systemd

On 07-12-17, Michael Biebl wrote: > > As has already been mentioned, active, local users can shutdown/reboot > the system without requiring a password. This is intended behaviour (for > the reasons already mentioned) and can indeed be overridden by custom > polkit rules. > Is there anywhere in

Re: Embarrassing security bug in systemd

On Wed 06 Dec 2017 at 15:25:10 (-0800), James H. H. Lampert wrote: > On 12/6/17, 2:53 PM, Michael Lange wrote: > >uh, I guess you ought to have used your time to check your machine and > >read some docs instead of figuring out how to best insult the debian > >developers ;) > >(scnr) > > Now, now,

Re: Embarrassing security bug in systemd

or shutdown the system they were sitting in front of. This led to a lot of really horrible solutions, like a bunch of setuid helper programs and one-off site specific hacks. Having this functionality standardized in one place is a net win for security, especially since there's also now a single

Re: Embarrassing security bug in systemd

On Wed 06 Dec 2017 at 22:52:17 (+0100), Urs Thuermann wrote: > Yesterday, my 10 years old son logged into my laptop running Debian > jessie using his account, and curiously asked if he is allowed to try > the /sbin/reboot command. Knowing I have a Linux system as opposed to > some crappy Win

Re: Embarrassing security bug in systemd

Am 06.12.2017 um 23:53 schrieb Michael Lange: > Hi, > > uh, I guess you ought to have used your time to check your machine and > read some docs instead of figuring out how to best insult the debian > developers ;) > (scnr) > > On 06 Dec 2017 22:52:17 +0100 > Urs Thuermann

Re: Embarrassing security bug in systemd

On 12/6/17, 2:53 PM, Michael Lange wrote: uh, I guess you ought to have used your time to check your machine and read some docs instead of figuring out how to best insult the debian developers ;) (scnr) Now, now, you walk up to the physical console on an AS/400, you're not going to be able to

Re: Embarrassing security bug in systemd

On 07/12/17 11:30, Roberto C. Sánchez wrote: I too consider this a rather serious bug. However, I do not see any evidence in the BTS [0] that such a bug has yet been reported against systemd. Not a bug. We can file this one alongside "console user has access to keyboard". Where did I out

Re: Embarrassing security bug in systemd

Hi, uh, I guess you ought to have used your time to check your machine and read some docs instead of figuring out how to best insult the debian developers ;) (scnr) On 06 Dec 2017 22:52:17 +0100 Urs Thuermann wrote: (...) > I wonder how can such a severe bug make it

Re: Embarrassing security bug in systemd

On Wed 06 Dec 2017 at 22:52:17 +0100, Urs Thuermann wrote: > Yesterday, my 10 years old son logged into my laptop running Debian > jessie using his account, and curiously asked if he is allowed to try > the /sbin/reboot command. Knowing I have a Linux system as opposed to > some crappy Win

Re: Embarrassing security bug in systemd

On Wed, Dec 6, 2017 at 9:52 PM, Urs Thuermann wrote: > Of course, my son doesn't have any special privileges, no entry in > /etc/sudoers, etc. But then I see > > $ ls -l /sbin/reboot > lrwxrwxrwx 1 root root 14 Apr 8 2017 /sbin/reboot -> /bin/systemctl > $

Re: Embarrassing security bug in systemd

On Wed, Dec 06, 2017 at 10:52:17PM +0100, Urs Thuermann wrote: Yesterday, my 10 years old son logged into my laptop running Debian jessie using his account, and curiously asked if he is allowed to try the /sbin/reboot command. Knowing I have a Linux system as opposed to some crappy Win machine,

Re: Embarrassing security bug in systemd

On Wed, Dec 06, 2017 at 10:52:17PM +0100, Urs Thuermann wrote: > Yesterday, my 10 years old son logged into my laptop running Debian > jessie using his account, and curiously asked if he is allowed to try > the /sbin/reboot command. Knowing I have a Linux system as opposed to > some crappy Win

Re: Embarrassing security bug in systemd

On 07/12/17 10:52, Urs Thuermann wrote: Yesterday, my 10 years old son logged into my laptop running Debian jessie using his account, and curiously asked if he is allowed to try the /sbin/reboot command. Knowing I have a Linux system as opposed to some crappy Win machine, I replied "sure, go

Embarrassing security bug in systemd

Yesterday, my 10 years old son logged into my laptop running Debian jessie using his account, and curiously asked if he is allowed to try the /sbin/reboot command. Knowing I have a Linux system as opposed to some crappy Win machine, I replied "sure, go ahead and try". Seconds later I was

Re: [Pkg-utopia-maintainers] network-manager-gnome - Ethernet - Security - 802.1x - Password can't be changed

k (nm-connection-editor:28348): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkNotebook ** Message: Cannot save connection due to error: Invalid setting 802.1X Security: missing EAP password ** Message: Connection validates and can be saved Segmentation fault

Re: [Pkg-utopia-maintainers] network-manager-gnome - Ethernet - Security - 802.1x - Password can't be changed

try. > > Workaround so far: The only way I found so far to effectively set the > password is to disable security completely and enable it back again to > define all values from scratch. It looks like you used gnome-control-center to change the password. Does it make a difference if yo

Re: network-manager-gnome - Ethernet - Security - 802.1x - Password can't be changed

the password is not really changed no matter how many times I try. > > Workaround so far: The only way I found so far to effectively set the > password is to disable security completely and enable it back again to > define all values from scratch. > > Additional info: > Passwords

network-manager-gnome - Ethernet - Security - 802.1x - Password can't be changed

everything seems fine (I apply and get no errors), but when I open the same settings back again the old password still remains, so the password is not really changed no matter how many times I try. Workaround so far: The only way I found so far to effectively set the password is to disable security

Not able to checkout Debian Security Testing Project from Debian SVN Repository

Dear Debian Security Team, I am facing the problem to checking out of Debian Secure-Testing project. I followed exact steps mentioned in the Debian Security tracker document still also I am not able to download Debian Secure testing project. My Allioth User Name: chittari-ami-guest Here

Re: Asterisk security update

Hi there On 04/10/17 20:10, Don Armstrong wrote: On Wed, 04 Oct 2017, Rob van der Putten wrote: The Asterisk security update seems to exclude amd64; I can't find a 13.14.1~dfsg-2+deb9u2_amd64.deb in pool. It's in stable-new: % rmadison asterisk|grep 9u2 asterisk | 1:13.14.1~dfsg-2

Re: Asterisk security update

On Wed, 04 Oct 2017, Rob van der Putten wrote: > The Asterisk security update seems to exclude amd64; I can't find a > 13.14.1~dfsg-2+deb9u2_amd64.deb in pool. It's in stable-new: % rmadison asterisk|grep 9u2 asterisk | 1:13.14.1~dfsg-2+deb9u2 | stable-new | source, arm64,

Re: Asterisk security update

On Wed, Oct 04, 2017 at 06:19:04PM +0200, Rob van der Putten wrote: > Hi there > > > On 04/10/17 17:33, Roberto C. Sánchez wrote: > > >On Wed, Oct 04, 2017 at 05:24:21PM +0200, Rob van der Putten wrote: > >> > >>The Asterisk security update seems to ex

Re: Asterisk security update

Hi there On 04/10/17 17:33, Roberto C. Sánchez wrote: On Wed, Oct 04, 2017 at 05:24:21PM +0200, Rob van der Putten wrote: The Asterisk security update seems to exclude amd64; I can't find a 13.14.1~dfsg-2+deb9u2_amd64.deb in pool. That is quite strange. There have been reports of uploads

Re: Asterisk security update

On Wed, Oct 04, 2017 at 05:24:21PM +0200, Rob van der Putten wrote: > Hi there > > > The Asterisk security update seems to exclude amd64; I can't find a > 13.14.1~dfsg-2+deb9u2_amd64.deb in pool. > > > Regards, > Rob > That is quite strange. There have been r

Asterisk security update

Hi there The Asterisk security update seems to exclude amd64; I can't find a 13.14.1~dfsg-2+deb9u2_amd64.deb in pool. Regards, Rob

Re: Security updates for Chromium on Debian Jessie

ppened with the previous >>>> update. >>>> >>>> Maybe I'm missing something and Chromium on Jessie is no longer getting >>>> security updates? >>> It seems that the maintainer is overworked and cannot provide Jessie >>> updates for chromium an

Re: security-cdn.debian.org weigert me?

Op 29-09-17 om 13:52 schreef Paul van der Vlis: > Ik vind het daarom toch vreemd dat hij connect naar > security-cdn.debian.org. Dat kan ik nergens uithalen. En morgen kan het > weer wat anders zijn. Volgens mij is men overgestapt van eigen Debian-services, naar het cloud-platform

Re: security-cdn.debian.org weigert me?

nd het daarom toch vreemd dat hij connect naar security-cdn.debian.org. Dat kan ik nergens uithalen. En morgen kan het weer wat anders zijn. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/

Re: security-cdn.debian.org weigert me?

On Fri, 29 Sep 2017 11:38:27 +0200 Paul van der Vlis wrote: > names="security.debian.org ftp.nl.debian.org popov.debian.org \ > popcon.debian.org ns1.vandervlis.nl ns2.vandervlis.nl" > > ip4="" > for name in $names; do >ip4="$ip4 `dig -t A +short $name | tr '\r \n' '

Re: Security updates for Chromium on Debian Jessie

with the previous update. Maybe I'm missing something and Chromium on Jessie is no longer getting security updates? It seems that the maintainer is overworked and cannot provide Jessie updates for chromium anymore[1]. Somebody else said he might be looking at it[2], but that was six weeks ago

Re: security-cdn.debian.org weigert me?

Hmm, op de probleem-machine verwijst dit naar >> mirror-conova-security.debian.org. En op een andere machine naar >> wieck.debian.org. Blijkbaar verschilt dit. >> >> Maar de melding gaat niet over security.debian.org, maar om >> security-cdn.debian.org, en dat verwijst naa

Re: Security updates for Chromium on Debian Jessie

e. >> >> Maybe I'm missing something and Chromium on Jessie is no longer getting >> security updates? > It seems that the maintainer is overworked and cannot provide Jessie > updates for chromium anymore[1]. Somebody else said he might be looking > at it[2], but that was six w

Re: security-cdn.debian.org weigert me?

ity.debian.org. En op een andere machine naar > wieck.debian.org. Blijkbaar verschilt dit. > > Maar de melding gaat niet over security.debian.org, maar om > security-cdn.debian.org, en dat verwijst naar > prod.debian.map.fastly.net. Zowel op de host als op de guests. De hos

Re: Security updates for Chromium on Debian Jessie

ybe I'm missing something and Chromium on Jessie is no longer getting > security updates? It seems that the maintainer is overworked and cannot provide Jessie updates for chromium anymore[1]. Somebody else said he might be looking at it[2], but that was six weeks ago and nothing happened

Security updates for Chromium on Debian Jessie

security updates? Thanks in advance. Kind regards, Daniel signature.asc Description: OpenPGP digital signature

Re: security-cdn.debian.org weigert me?

s naar? security.debian.org verwijst daar ook naar villa.debian.org. Hmm, op de probleem-machine verwijst dit naar mirror-conova-security.debian.org. En op een andere machine naar wieck.debian.org. Blijkbaar verschilt dit. Maar de melding gaat niet over security.debian.org, maar om security-cdn.debian.org,

Re: security-cdn.debian.org weigert me?

ook naar villa.debian.org. Hmm, op de probleem-machine verwijst dit naar mirror-conova-security.debian.org. En op een andere machine naar wieck.debian.org. Blijkbaar verschilt dit. Maar de melding gaat niet over security.debian.org, maar om security-cdn.debian.org, en dat verwijst naar prod.debi

Re: security-cdn.debian.org weigert me?

Op Thu, 28 Sep 2017 11:08:53 +0200 schreef Paul van der Vlis <p...@vandervlis.nl>: Op 27-09-17 om 20:41 schreef Geert Stappers: On Wed, Sep 27, 2017 at 04:47:36PM +0200, Paul van der Vlis wrote: Hoi, Een machine geeft sinds een paar dagen foutmeldingen bij het ophalen van se

Security updates (Was: (solved) how to roll back to jessie)

On 04/09/17 02:58, Long Wind wrote: > i do not install security update > and it not cause trouble for me Hello. I am wondering: Why do you choose to not to install security updates? There seems to be nothing to gain and much to lose with that choice. -- Do not eat animals; respect them

Re: security issues

On Sunday 27 August 2017 12:22:30 Mike McClain wrote: > On Sat, Aug 26, 2017 at 04:35:21PM -0400, Gene Heskett wrote: > > I have had the ultimate revenge on those who were enemies at one > > time, I've outlived the turkeys without doing anything to hasten > > their demise. ;-) > > I thought that

Re: security issues

On Sat, Aug 26, 2017 at 04:35:21PM -0400, Gene Heskett wrote: > > I have had the ultimate revenge on those who were enemies at one time, > I've outlived the turkeys without doing anything to hasten their > demise. ;-) > I thought that was worthy of being a tagline. Hope you don't mind. Mike --

Re: security issues

On Saturday 26 August 2017 15:43:40 Brian wrote: > [Lots of snipping] > > On Sat 26 Aug 2017 at 15:25:53 -0400, Gene Heskett wrote: > > On Saturday 26 August 2017 14:51:41 Brian wrote: > > > That's what you think! But while you are slumbering, she is > > > emailing friends and talking with Donald

Re: security issues

[Lots of snipping] On Sat 26 Aug 2017 at 15:25:53 -0400, Gene Heskett wrote: > On Saturday 26 August 2017 14:51:41 Brian wrote: > > > That's what you think! But while you are slumbering, she is emailing > > friends and talking with Donald on Twitter. Never underestimate a > > woman's ability to

Re: security issues

On Saturday 26 August 2017 15:25:53 Gene Heskett wrote: > > > install any of the firewall type stuff, dd-wrt in the router is > > > the best guard dog. I've been running some form of it for 15 or > > > more years, and have not been breached. > > > > Isn't dd-wrt only suitable for particular

Re: security issues

gt; > alguna empresa que de soporte. > > > > > > > > Muchas gracias, Roberto > > > > > > > > > > > > Good afternoon, I have been debian 8.9 user for 2 years. > > > > I have security issues that force me to reinstall the

Re: security issues

gt; He conocido herramientas como: > > > Lynis, openval, nessus, grsecurity,apparmor, selinux, etc > > > Si puede alguien con conocimientos de seguridad ayudarme. O hay > > > alguna empresa que de soporte. > > > > > > Muchas gracias, Roberto > >

Re: security issues

> > Si puede alguien con conocimientos de seguridad ayudarme. O hay > > alguna empresa que de soporte. > > > > Muchas gracias, Roberto > > > > > > Good afternoon, I have been debian 8.9 user for 2 years. > > I have security issues that force me to reinstal

Re: security issues

>> empresa que de soporte. >> >> Muchas gracias, Roberto >> >> >> Good afternoon, I have been debian 8.9 user for 2 years. >> I have security issues that force me to reinstall the system often, once a >> year. >> I have read documents and help

Re: security issues

curity,apparmor, selinux, etc > Si puede alguien con conocimientos de seguridad ayudarme. O hay alguna > empresa que de soporte. > > Muchas gracias, Roberto > > > Good afternoon, I have been debian 8.9 user for 2 years. > I have security issues that force me to reinstall th

<    4   5   6   7   8   9   10   11   12   13   >