On Tue, 2016-01-26 at 11:51 +, David Woodhouse wrote:
> It does even make a little bit of sense, if the most sensitive item
> on the computer in question *is* the VPN certificate
That would certainly be the case for my VPN setup... it's just there so
I can access the work network from my perso
If the hostname file is a symbolic link, follow it to find where the
real file is located, otherwise g_file_set_contents will attempt to
replace the link with a plain file.
---
src/settings/nm-settings.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/setting
Hi,
here's the patch to simplify blob handling.
Cheers,
Matthias
>From 469b5974cb539a7cfc2d79b489f58e98e79424dc Mon Sep 17 00:00:00 2001
From: Matthias Berndt
Date: Tue, 26 Jan 2016 22:55:24 +0100
Subject: [PATCH] simplify blob handling
---
properties/import-export.c | 29 +
On Tue, 2016-01-26 at 13:41 -0500, Chuck Anderson wrote:
> While we're on this topic, what about other types of invalid MAC
> addresses? Like ones with the Multicast bit set (odd first octet),
> or
> ones with the LAA (Locallay Administered Address) bit set (2nd least
> significant bit of first oc
First, cb751012a2f4b8ef236eab2a7c65687c99205806 mistakenly converted the
act_stage_context_step() in connect_ready() to connect_context_clear()
instead of connect_context_step(). This would cause the IP Type retry
logic to fail and no further types to be tried. It also throws
away the ctx->first_
While we're on this topic, what about other types of invalid MAC
addresses? Like ones with the Multicast bit set (odd first octet), or
ones with the LAA (Locallay Administered Address) bit set (2nd least
significant bit of first octet, e,g, x2: x6: xa: xe:).
For Multicast Ethernet addresses, I do
Drivers are stupid, and just like the platform ignores an all zeros
permanent address, so should it ignore all ones.
NetworkManager[509]: [1453743778.854919] [devices/nm-device.c:8885]
nm_device_update_hw_address(): [0x190370] (eth0): hardware address now
86:18:52:xx:xx:xx
NetworkManager[509]:
On Mon, 2016-01-25 at 22:59 +0100, Beniamino Galvani wrote:
> On Mon, Jan 25, 2016 at 12:59:22PM -0600, Dan Williams wrote:
> > From 2370f508df8400b424fec032f8314cea97fdbaef Mon Sep 17 00:00:00
> > 2001
> > From: Dan Williams
> > Date: Wed, 20 Jan 2016 13:52:59 -0600
> > Subject: [PATCH] dns: clea
On Mon, 2016-01-25 at 12:59 -0600, Dan Williams wrote:
> From 2370f508df8400b424fec032f8314cea97fdbaef Mon Sep 17 00:00:00
> 2001
> From: Dan Williams
> Date: Wed, 20 Jan 2016 13:52:59 -0600
> Subject: [PATCH] dns: clean up error paths in dns-manager
>
> Specifically for resolvconf, if the write
On Tue, 2016-01-26 at 10:01 +0100, Matthias Berndt wrote:
>
>
> > OTOH if she is keeping her cert deliberately secure on an encrypted USB
> > storage device, and it gets copied to the unencrypted hard drive, she
> > might not be able to connect tomorrow because she's been *fired* for
> > this bre
On Mon, 2016-01-25 at 22:57 +, Joel Holdsworth wrote:
> If the hostname file is a symbolic link, follow it to find where the
> real file is located, otherwise g_file_set_contents will attempt to
> replace the link with a plain file.
> ---
> src/settings/nm-settings.c | 14 --
> 1 f
Dan Williams writes:
> Drivers are stupid,
They don't *have* to be, you know :)
I did wonder if we should make the usbnet framework reject such
addresses after seeing this a while ago:
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNum
>OTOH if she is keeping her cert deliberately secure on an encrypted USB
>storage device, and it gets copied to the unencrypted hard drive, she
>might not be able to connect tomorrow because she's been *fired* for
>this breach of security policy.
What kind of security policy requires you to encr
13 matches
Mail list logo
