Document removal of ecryptfs-utils from Buster

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Document removal of ecryptfs-utils from Buster

Curt
I was preparing an upgrade to Buster until I saw this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956

 Due to #765854 ecryptfs-utils has been removed from Buster.
 The kernel module (ecryptfs.ko) is still built but depending on the
 upgrade path users will be unable to mount their encrypted home
 directories (pam module, ecryptfs-mount-private missing).
 So they should probably be strongly advised to not upgrade.

"probably be strongly advised to not upgrade" is rather awkward and kind
of pathetically broken.

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Andrea Borgia
Il 30/06/19 11:52, Curt ha scritto:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
>
>   Due to #765854 ecryptfs-utils has been removed from Buster.
>   The kernel module (ecryptfs.ko) is still built but depending on the
>   upgrade path users will be unable to mount their encrypted home
>   directories (pam module, ecryptfs-mount-private missing).
>   So they should probably be strongly advised to not upgrade.

Should I count myself lucky that I have two systems running "testing"
with also "stable" sources? Perhaps it's time to mark the package as
"hold" :)

I'd be interested to know if there is an alternative: not so much for my
desktop but my laptop really needs it. Thanks for the heads up, though.

Regards,
Andrea.

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Sven Hartge-5
Andrea Borgia <[hidden email]> wrote:
> Il 30/06/19 11:52, Curt ha scritto:

>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
>>
>>   Due to #765854 ecryptfs-utils has been removed from Buster.
>>   The kernel module (ecryptfs.ko) is still built but depending on the
>>   upgrade path users will be unable to mount their encrypted home
>>   directories (pam module, ecryptfs-mount-private missing).
>>   So they should probably be strongly advised to not upgrade.

> Should I count myself lucky that I have two systems running "testing"
> with also "stable" sources? Perhaps it's time to mark the package as
> "hold" :)

> I'd be interested to know if there is an alternative: not so much for
> my desktop but my laptop really needs it. Thanks for the heads up,
> though.

You could compile ecryptfs-utils on Buster manually to get the
dependencies right.

Or keep stretch in sources.list but this will not work forever, as soon
as Stretch gets archived it will break.

Other than that: Reinstalling the system with full disk encryption or
just copying the files from the ecryptfs and then removing it are the
only real other options.

But I foresee a big lashback once people not noticing this upgrade to
Buster to then just discover that their system is completely broken.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Gene Heskett-4
On Sunday 30 June 2019 12:17:48 Sven Hartge wrote:

> Andrea Borgia <[hidden email]> wrote:
> > Il 30/06/19 11:52, Curt ha scritto:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
> >>
> >>   Due to #765854 ecryptfs-utils has been removed from Buster.
> >>   The kernel module (ecryptfs.ko) is still built but depending on
> >> the upgrade path users will be unable to mount their encrypted home
> >> directories (pam module, ecryptfs-mount-private missing). So they
> >> should probably be strongly advised to not upgrade.
> >
> > Should I count myself lucky that I have two systems running
> > "testing" with also "stable" sources? Perhaps it's time to mark the
> > package as "hold" :)
> >
> > I'd be interested to know if there is an alternative: not so much
> > for my desktop but my laptop really needs it. Thanks for the heads
> > up, though.
>
> You could compile ecryptfs-utils on Buster manually to get the
> dependencies right.
>
> Or keep stretch in sources.list but this will not work forever, as
> soon as Stretch gets archived it will break.
>
> Other than that: Reinstalling the system with full disk encryption or
> just copying the files from the ecryptfs and then removing it are the
> only real other options.
>
> But I foresee a big lashback once people not noticing this upgrade to
> Buster to then just discover that their system is completely broken.
>
> Grüße,
> Sven.

At this point, I'd call it a buster delaying bug.  That last is going to
cost too many that can't ignore it and don't have unencrypted backups.
Thats going to be a lot of very bad PR.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Andrea Borgia
In reply to this post by Sven Hartge-5
Il 30/06/19 18:17, Sven Hartge ha scritto:


> Other than that: Reinstalling the system with full disk encryption or
> just copying the files from the ecryptfs and then removing it are the
> only real other options.

I'll explore f.d.e. for the laptop, I guess the desktop can live just
fine with a plain setup.


> But I foresee a big lashback once people not noticing this upgrade to
> Buster to then just discover that their system is completely broken.

Yup, this isn't going to be pretty.

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Tixy-2
In reply to this post by Sven Hartge-5
On Sun, 2019-06-30 at 18:17 +0200, Sven Hartge wrote:

> Andrea Borgia <[hidden email]> wrote:
> > Il 30/06/19 11:52, Curt ha scritto:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
> > >
> > >   Due to #765854 ecryptfs-utils has been removed from Buster.
> > >   The kernel module (ecryptfs.ko) is still built but depending on
> > > the
> > >   upgrade path users will be unable to mount their encrypted home
> > >   directories (pam module, ecryptfs-mount-private missing).
> > >   So they should probably be strongly advised to not upgrade.
> > Should I count myself lucky that I have two systems running
> > "testing"
> > with also "stable" sources? Perhaps it's time to mark the package
> > as
> > "hold" :)
> > I'd be interested to know if there is an alternative: not so much
> > for
> > my desktop but my laptop really needs it. Thanks for the heads up,
> > though.
>
> You could compile ecryptfs-utils on Buster manually to get the
> dependencies right.
>
> Or keep stretch in sources.list but this will not work forever, as
> soon
> as Stretch gets archived it will break.
>
> Other than that: Reinstalling the system with full disk encryption or
> just copying the files from the ecryptfs and then removing it are the
> only real other options.

Or if you have (or can make) a new disk partition, use dm-crypt to
encrypt that and put the file system on that that people want encrypted
(for /home?).

Personally, for several releases I've used dm-crypt with LUKS for a
partiton containing everything apart from /boot. (Done using Debian
installer when creating a system).

--
Tixy

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

deloptes-2
Tixy wrote:

> Or if you have (or can make) a new disk partition, use dm-crypt to
> encrypt that and put the file system on that that people want encrypted
> (for /home?).
>
> Personally, for several releases I've used dm-crypt with LUKS for a
> partiton containing everything apart from /boot. (Done using Debian
> installer when creating a system).

+1

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Curt
In reply to this post by Andrea Borgia
On 2019-06-30, Andrea Borgia <[hidden email]> wrote:

> Il 30/06/19 11:52, Curt ha scritto:
>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
>>
>>   Due to #765854 ecryptfs-utils has been removed from Buster.
>>   The kernel module (ecryptfs.ko) is still built but depending on the
>>   upgrade path users will be unable to mount their encrypted home
>>   directories (pam module, ecryptfs-mount-private missing).
>>   So they should probably be strongly advised to not upgrade.
>
> Should I count myself lucky that I have two systems running "testing"
> with also "stable" sources? Perhaps it's time to mark the package as
> "hold" :)
>
> I'd be interested to know if there is an alternative: not so much for my
> desktop but my laptop really needs it. Thanks for the heads up, though.

I haven't yet investigated the alternatives.

I guess I will be rolling back the encryption and purging the
incriminated software. I have nagging doubts about my encrypted swap and
whether I need to roll that back, too. I guess I will.

Another, less serious, gotcha for those inveterate upgraders and newbies
who don't read the release notes is that
'/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
mechanism for defining device names. This mechanism (automagically)
permitted users upgrading from Wheezy to Stretch (where the old-style
names were deprecated) to continue using their obsolete, legacy
interface names (eth0, anyone?).  

Me, I migrated to the new-fangled denominations as per the instructions
at the link below to obviate the eventual loss of network connectivity,
which is a bummer when you don't what you're doing and all the help
available is at the other end of the severed wire.

https://www.debian.org/releases///buster/s390x/release-notes/ch-information.en.html#migrate-interface-names

The Wanderer and other recalcitrants allergic to progress (just kidding)
can still resort to the 'net.ifname=0 kernel' command line option for
relief.

> Regards,
> Andrea.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Jonathan Dowland
In reply to this post by Gene Heskett-4
On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
>At this point, I'd call it a buster delaying bug.  That last is going to
>cost too many that can't ignore it and don't have unencrypted backups.
>Thats going to be a lot of very bad PR.

It's the release teams call, generally speaking, and one of the things
they might factor in is the size of the user-base for the troublesome
package. I'm surprised to find that it's extremely small according to
popcon data: less than 1% of reporters:
https://qa.debian.org/popcon.php?package=ecryptfs-utils

Compare just two alternatives:

encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Gene Heskett-4
On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:

> On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> >At this point, I'd call it a buster delaying bug.  That last is going
> > to cost too many that can't ignore it and don't have unencrypted
> > backups. Thats going to be a lot of very bad PR.
>
> It's the release teams call, generally speaking, and one of the things
> they might factor in is the size of the user-base for the troublesome
> package. I'm surprised to find that it's extremely small according to
> popcon data: less than 1% of reporters:
> https://qa.debian.org/popcon.php?package=ecryptfs-utils
>
> Compare just two alternatives:
>
> encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
> cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup

That does put a better light on it.  From the comments so far, I was
thinking I'm one of the few not using it. I've depended on dd-wrt
between me and the internet for the last 16 years, and even before that
I was on dialup and the dialup folks didn't have enough bandwidth to
attract the black hats, so I've never been touched.

With all the publicity this thread has given the issue, I'll change my
mind (as if it matters to the team :) and say adequate notice and
mitigating paths seems to have been given. Those that are using it I'd
call pretty advanced and are reading this list just for the notices
given so they shouldn't be surprised. So I'll do an Andy Capp and
shuddup.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Curt
On 2019-07-01, Gene Heskett <[hidden email]> wrote:

> On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
>
>> On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
>> >At this point, I'd call it a buster delaying bug.  That last is going
>> > to cost too many that can't ignore it and don't have unencrypted
>> > backups. Thats going to be a lot of very bad PR.
>>
>> It's the release teams call, generally speaking, and one of the things
>> they might factor in is the size of the user-base for the troublesome
>> package. I'm surprised to find that it's extremely small according to
>> popcon data: less than 1% of reporters:
>> https://qa.debian.org/popcon.php?package=ecryptfs-utils
>>
>> Compare just two alternatives:
>>
>> encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
>> cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup
>
> That does put a better light on it.  From the comments so far, I was

The light's not switching on for me, Gene. I'm trying to figure out
Popularity Contest and what all those statistics mean.

Let's compare encfs and ecryptfs-utils with a bit more granularity.

NAME            NUMBER       %      RANK       NUMBER         %     RANK  ...
____________________________________________________________________________
ecryptfs-utils  1651       0.85%    10510      1066         0.58%   3632  ...
encfs           2231       1.14%     9233       630         0.34%   4574  ...

The second triad of NUMBER % RANK columns corresponds to the number of people
using the package regularly* and by that metric ecryptfs-utils beats encfs by a
relative long shot (1066 to 630, 0.58% to 0.34%). It's true cryptsetup appears
to be the clear winner of the three, though it's not entirely comparable to the
other two use-case/implementation-wise (block device level encryption as
compared to file system level encryption).

Maybe I'm getting this all wrong.

*whatever that may denote in this case, exactly

> thinking I'm one of the few not using it. I've depended on dd-wrt
> between me and the internet for the last 16 years, and even before that
> I was on dialup and the dialup folks didn't have enough bandwidth to
> attract the black hats, so I've never been touched.



Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

David Wright-3
In reply to this post by Gene Heskett-4
On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:

> On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> > On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> > >At this point, I'd call it a buster delaying bug.  That last is going
> > > to cost too many that can't ignore it and don't have unencrypted
> > > backups. Thats going to be a lot of very bad PR.
> >
> > It's the release teams call, generally speaking, and one of the things
> > they might factor in is the size of the user-base for the troublesome
> > package. I'm surprised to find that it's extremely small according to
> > popcon data: less than 1% of reporters:
> > https://qa.debian.org/popcon.php?package=ecryptfs-utils
> >
> > Compare just two alternatives:
> >
> > encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
> > cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup
>
> That does put a better light on it.  From the comments so far, I was
> thinking I'm one of the few not using it. I've depended on dd-wrt
> between me and the internet for the last 16 years, and even before that
> I was on dialup and the dialup folks didn't have enough bandwidth to
> attract the black hats, so I've never been touched.

I was under the impression that these two forms of security, firewalls
and encryption, are completely orthogonal. Once you've unlocked, say,
an encrypted partition, you're now reliant on the firewall to keep
strangers out of your files. OTOH a perfect firewall is of no benefit
when your laptop is stolen.

> With all the publicity this thread has given the issue, I'll change my
> mind (as if it matters to the team :) and say adequate notice and
> mitigating paths seems to have been given. Those that are using it I'd
> call pretty advanced and are reading this list just for the notices
> given so they shouldn't be surprised. So I'll do an Andy Capp and
> shuddup.

The grey area is for me is the relative benefit of encrypting file by
file compared with the whole partition. Assuming that there's just one
passphrase involved in each scenario, is more protection given by the
former method? After all, once a partition is unlocked, all users on
the system are able to read all the files, subject to the normal unix
permissions, ACLs, etc.

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Jonathan Dowland
On Mon, Jul 01, 2019 at 08:33:35AM -0500, David Wright wrote:
>The grey area is for me is the relative benefit of encrypting file by
>file compared with the whole partition. Assuming that there's just one
>passphrase involved in each scenario, is more protection given by the
>former method? After all, once a partition is unlocked, all users on
>the system are able to read all the files, subject to the normal unix
>permissions, ACLs, etc.

One fairly attractive feature of the file (or filesystem) level encryption is
it can be layered on top of an existing partition/install relatively easily, no
need to resort to repartitioning. I think this was one reason that it was a
recommended approach in Ubuntu, at least, integrated to some extent with their
installer (Although I think no longer). It never reached that level of support
in Debian, which offers block-level encryption in the installer instead.

Two drawbacks:

it does not protect you from accidentally writing sensitive information to a
file outside of that area (/tmp, or /var/tmp, or inside an email in exim's
spool directory under /var, or in paged-out virtual memory written to an
unencrypted swap space, or who knows where else).

the implementations are quirky (layered filesystems have always been, and
continue to be, awkward, with some semantic corner-cases still misbehaving
today with overlay2 and container work loads)


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Jonathan Dowland
In reply to this post by Curt
On Mon, Jul 01, 2019 at 01:14:07PM -0000, Curt wrote:
>The second triad of NUMBER % RANK columns corresponds to the number of people
>using the package regularly* and by that metric ecryptfs-utils beats encfs by a
>relative long shot (1066 to 630, 0.58% to 0.34%).

"relative" to what? That's what the percentage (as oppose to absolute numbers)
gives you, the relative comparison with all packages. The difference in that
frame of reference is virtually noise.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Curt
On 2019-07-01, Jonathan Dowland <[hidden email]> wrote:
> On Mon, Jul 01, 2019 at 01:14:07PM -0000, Curt wrote:
>>The second triad of NUMBER % RANK columns corresponds to the number of people
>>using the package regularly* and by that metric ecryptfs-utils beats encfs by a
>>relative long shot (1066 to 630, 0.58% to 0.34%).
>
> "relative" to what? That's what the percentage (as oppose to absolute
> numbers)

I understood those statistics to mean that 1066 people use
ecryptfs-utils regularly and 630 use encfs regularly (giving
ecryptfs-utils more regular users than encfs by a relatively large
margin---nearly the double). The 1.14%/>1% metric you mentioned to
illustrate your point seemed to me therefore to be a little misleading.


> gives you, the relative comparison with all packages. The difference in that
> frame of reference is virtually noise.
>


--
“Decisions are never really made – at best they manage to emerge, from a chaos
of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Greg Wooledge
In reply to this post by Curt
On Mon, Jul 01, 2019 at 07:47:35AM -0000, Curt wrote:
> Another, less serious, gotcha for those inveterate upgraders and newbies
> who don't read the release notes is that
> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
> mechanism for defining device names.

For whatever it's worth, when I upgraded this machine from stretch to
buster a couple months ago, it continued using eth0 as the interface
name without any immediately obvious issues.  I did the conversion to
"predictable interface names" anyway, just in case there might be some
subtle problem that I wasn't yet seeing.

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Curt
On 2019-07-01, Greg Wooledge <[hidden email]> wrote:

> On Mon, Jul 01, 2019 at 07:47:35AM -0000, Curt wrote:
>> Another, less serious, gotcha for those inveterate upgraders and newbies
>> who don't read the release notes is that
>> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
>> mechanism for defining device names.
>
> For whatever it's worth, when I upgraded this machine from stretch to
> buster a couple months ago, it continued using eth0 as the interface
> name without any immediately obvious issues.  I did the conversion to
> "predictable interface names" anyway, just in case there might be some
> subtle problem that I wasn't yet seeing.
>
>

And you had that device name defined (as I did) in
'/etc/udev/rules.d/70-persistent-net.rules' when you upgraded?

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Greg Wooledge
On Mon, Jul 01, 2019 at 02:15:50PM -0000, Curt wrote:

> On 2019-07-01, Greg Wooledge <[hidden email]> wrote:
> > On Mon, Jul 01, 2019 at 07:47:35AM -0000, Curt wrote:
> >> Another, less serious, gotcha for those inveterate upgraders and newbies
> >> who don't read the release notes is that
> >> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
> >> mechanism for defining device names.
> >
> > For whatever it's worth, when I upgraded this machine from stretch to
> > buster a couple months ago, it continued using eth0 as the interface
> > name without any immediately obvious issues.  I did the conversion to
> > "predictable interface names" anyway, just in case there might be some
> > subtle problem that I wasn't yet seeing.
> >
> >
>
> And you had that device name defined (as I did) in
> '/etc/udev/rules.d/70-persistent-net.rules' when you upgraded?

Yes.  In fact it's still there, but I commented it out by hand after
the buster upgrade.

wooledg:~$ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x15b7 (e1000e)
# SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:8c:fd:c3:89:e0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Curt
On 2019-07-01, Greg Wooledge <[hidden email]> wrote:

>> >
>> > For whatever it's worth, when I upgraded this machine from stretch to
>> > buster a couple months ago, it continued using eth0 as the interface
>> > name without any immediately obvious issues.  I did the conversion to
>> > "predictable interface names" anyway, just in case there might be some
>> > subtle problem that I wasn't yet seeing.
>>
>> And you had that device name defined (as I did) in
>> '/etc/udev/rules.d/70-persistent-net.rules' when you upgraded?
>
> Yes.  In fact it's still there, but I commented it out by hand after
> the buster upgrade.
>
> wooledg:~$ cat /etc/udev/rules.d/70-persistent-net.rules
> # This file was automatically generated by the /lib/udev/write_net_rules
> # program, run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single
> # line, and change only the value of the NAME= key.
>
> # PCI device 0x8086:0x15b7 (e1000e)
> # SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:8c:fd:c3:89:e0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>
>

Assuming the name was not also defined elsewhere, I'm at a loss to know
why the release notes for Buster state

 ...you should be aware that udev in buster no
 longer supports the mechanism of defining their names via
 /etc/udev/rules.d/70-persistent-net.rules. To avoid the danger of your
 machine losing networking after the upgrade to buster, it is recommended
 that you migrate in advance to the new naming scheme...

Well, I'm enp6s0 anyway now and somehow feel better about it.


Reply | Threaded
Open this post in threaded view
|

Re: Document removal of ecryptfs-utils from Buster

Gene Heskett-4
In reply to this post by Curt
On Monday 01 July 2019 09:14:07 Curt wrote:

> On 2019-07-01, Gene Heskett <[hidden email]> wrote:
> > On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> >> On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> >> >At this point, I'd call it a buster delaying bug.  That last is
> >> > going to cost too many that can't ignore it and don't have
> >> > unencrypted backups. Thats going to be a lot of very bad PR.
> >>
> >> It's the release teams call, generally speaking, and one of the
> >> things they might factor in is the size of the user-base for the
> >> troublesome package. I'm surprised to find that it's extremely
> >> small according to popcon data: less than 1% of reporters:
> >> https://qa.debian.org/popcon.php?package=ecryptfs-utils
> >>
> >> Compare just two alternatives:
> >>
> >> encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
> >> cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup
> >
> > That does put a better light on it.  From the comments so far, I was
>
> The light's not switching on for me, Gene. I'm trying to figure out
> Popularity Contest and what all those statistics mean.
>
> Let's compare encfs and ecryptfs-utils with a bit more granularity.
>
> NAME            NUMBER       %      RANK       NUMBER         %    
> RANK  ...
> ______________________________________________________________________
>______ ecryptfs-utils  1651       0.85%    10510      1066        
> 0.58%   3632  ... encfs           2231       1.14%     9233       630
>        0.34%   4574  ...
>
> The second triad of NUMBER % RANK columns corresponds to the number of
> people using the package regularly* and by that metric ecryptfs-utils
> beats encfs by a relative long shot (1066 to 630, 0.58% to 0.34%).
> It's true cryptsetup appears to be the clear winner of the three,
> though it's not entirely comparable to the other two
> use-case/implementation-wise (block device level encryption as
> compared to file system level encryption).
>
I'm not sure I understand all the numbers either. OTOH, paranoia that
makes a few use it does seem to be related to the hand of a beerholder.

> Maybe I'm getting this all wrong.

Its entirely possible we're both wrong, and that caldrons of hot tar and
old pillows will materialize in this space. I personally have never felt
the need to use it, so I haven't. To me, its something else that guy
Murphy can break, at the most inopportune time of course.  He drinks my
last beer just often enough to remind me he's about the place. :)

> *whatever that may denote in this case, exactly
>
> > thinking I'm one of the few not using it. I've depended on dd-wrt
> > between me and the internet for the last 16 years, and even before
> > that I was on dialup and the dialup folks didn't have enough
> > bandwidth to attract the black hats, so I've never been touched.


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

12