Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #210495 > unrolled thread

Document removal of ecryptfs-utils from Buster

Back to article view | Back to linux.debian.user

Contents

  Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-06-30 12:00 +0200
    Re: Document removal of ecryptfs-utils from Buster Andrea Borgia <andrea@borgia.bo.it> - 2019-06-30 17:40 +0200
      Re: Document removal of ecryptfs-utils from Buster Sven Hartge <sven@svenhartge.de> - 2019-06-30 18:20 +0200
        Re: Document removal of ecryptfs-utils from Buster Gene Heskett <gheskett@shentel.net> - 2019-06-30 18:50 +0200
          Re: Document removal of ecryptfs-utils from Buster Jonathan Dowland <jmtd@debian.org> - 2019-07-01 10:00 +0200
            Re: Document removal of ecryptfs-utils from Buster Gene Heskett <gheskett@shentel.net> - 2019-07-01 12:10 +0200
              Re: Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-07-01 15:20 +0200
                Re: Document removal of ecryptfs-utils from Buster Jonathan Dowland <jmtd@debian.org> - 2019-07-01 15:50 +0200
                  Re: Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-07-01 16:10 +0200
                Re: Document removal of ecryptfs-utils from Buster Gene Heskett <gheskett@shentel.net> - 2019-07-01 22:00 +0200
              Re: Document removal of ecryptfs-utils from Buster David Wright <deblis@lionunicorn.co.uk> - 2019-07-01 15:40 +0200
                Re: Document removal of ecryptfs-utils from Buster Jonathan Dowland <jmtd@debian.org> - 2019-07-01 15:50 +0200
                Re: Document removal of ecryptfs-utils from Buster Gene Heskett <gheskett@shentel.net> - 2019-07-01 22:00 +0200
                  Re: Document removal of ecryptfs-utils from Buster Jonathan Dowland <jmtd@debian.org> - 2019-07-01 22:20 +0200
                  Re: Document removal of ecryptfs-utils from Buster David Wright <deblis@lionunicorn.co.uk> - 2019-07-02 01:50 +0200
                    Re: Document removal of ecryptfs-utils from Buster Gene Heskett <gheskett@shentel.net> - 2019-07-02 11:20 +0200
                      Re: Document removal of ecryptfs-utils from Buster Richard Hector <richard@walnut.gen.nz> - 2019-07-07 02:10 +0200
        Re: Document removal of ecryptfs-utils from Buster Andrea Borgia <andrea@borgia.bo.it> - 2019-06-30 19:00 +0200
        Re: Document removal of ecryptfs-utils from Buster Tixy <tixy@yxit.co.uk> - 2019-06-30 19:50 +0200
          Re: Document removal of ecryptfs-utils from Buster deloptes <deloptes@gmail.com> - 2019-06-30 21:20 +0200
      Re: Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-07-01 09:50 +0200
        Re: Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-07-01 16:20 +0200
          Re: Document removal of ecryptfs-utils from Buster Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-01 16:50 +0200
            Re: Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-07-01 17:50 +0200
        Re: Document removal of ecryptfs-utils from Buster Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-01 16:20 +0200
        70-persistent-net-rules no longer supported? (Was Re: Document removal  of ecryptfs-utils from Buster) The Wanderer <wanderer@fastmail.fm> - 2019-07-02 14:10 +0200
          Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Curt <curty@free.fr> - 2019-07-02 14:40 +0200
            Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) The Wanderer <wanderer@fastmail.fm> - 2019-07-02 15:00 +0200
              Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) The Wanderer <wanderer@fastmail.fm> - 2019-07-02 15:20 +0200
              Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-02 15:20 +0200
              Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Curt <curty@free.fr> - 2019-07-02 16:20 +0200
                Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) The Wanderer <wanderer@fastmail.fm> - 2019-07-02 16:30 +0200
                  Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Brian <ad44@cityscape.co.uk> - 2019-07-02 21:20 +0200
                    Re: 70-persistent-net-rules no longer supported? Stephan Seitz <stse+debian@fsing.rootsland.net> - 2019-07-03 09:20 +0200
                      Re: 70-persistent-net-rules no longer supported? Curt <curty@free.fr> - 2019-07-03 10:10 +0200
                      Re: 70-persistent-net-rules no longer supported? Brian <ad44@cityscape.co.uk> - 2019-07-03 11:30 +0200
                  Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Geoff <unit735@bigpond.com> - 2019-07-03 04:30 +0200
          Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 11:20 +0200

Page 1 of 2  [1] 2  Next page →

#210495 — Document removal of ecryptfs-utils from Buster

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.

[toc] | [next] | [standalone]

#210502

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.

[toc] | [prev] | [next] | [standalone]

#210504

Andrea Borgia <andrea@borgia.bo.it> 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.

[toc] | [prev] | [next] | [standalone]

#210505

On Sunday 30 June 2019 12:17:48 Sven Hartge wrote:

> Andrea Borgia <andrea@borgia.bo.it> 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>

[toc] | [prev] | [next] | [standalone]

#210519

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.

[toc] | [prev] | [next] | [standalone]

#210523

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>

[toc] | [prev] | [next] | [standalone]

#210533

On 2019-07-01, Gene Heskett <gheskett@shentel.net> 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.

[toc] | [prev] | [next] | [standalone]

#210538

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.

[toc] | [prev] | [next] | [standalone]

#210540

On 2019-07-01, Jonathan Dowland <jmtd@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#210568

On Monday 01 July 2019 09:14:07 Curt wrote:

> On 2019-07-01, Gene Heskett <gheskett@shentel.net> 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>

[toc] | [prev] | [next] | [standalone]

#210535

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.

[toc] | [prev] | [next] | [standalone]

#210536

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.

[toc] | [prev] | [next] | [standalone]

#210569

On Monday 01 July 2019 09:33:35 David Wright wrote:

> 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.

Whole filesystem encryption would be a total non-starter for me.  File by 
file with different passwd's according to whats in the file would make 
far more sense to me. Thats my $0.02.

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>

[toc] | [prev] | [next] | [standalone]

#210573

On Mon, Jul 01, 2019 at 03:56:14PM -0400, Gene Heskett wrote:
>Whole filesystem encryption would be a total non-starter for me.  File by
>file with different passwd's according to whats in the file would make
>far more sense to me. Thats my $0.02.

In which case none of cryptsetup/luks/dm-crypt, ecryptfs or encfs are of
use to you. GnuPG could do what you describe there, amongst other things.

-- 

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

[toc] | [prev] | [next] | [standalone]

#210582

On Mon 01 Jul 2019 at 15:56:14 (-0400), Gene Heskett wrote:
> On Monday 01 July 2019 09:33:35 David Wright wrote:
> > 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.
> 
> Whole filesystem encryption would be a total non-starter for me.

Fair enough. Could you reveal why, or are your reasons cryptic too?

> File by 
> file with different passwd's according to whats in the file would make 
> far more sense to me. Thats my $0.02.

I can't see how anyone would cope with a scheme like that. How would
you remember all those passwords?

OTOH I can see that each file must have an individual encryption key,
but the encryption scheme looks after generating those. Otherwise
you would have a large sample of encrypted but known-cleartext files
available for cracking attempts. (Remember that the filenames are not
encrypted, and many files on a system will have entirely predictable
contents, eg much of /usr, your Debian package cache, and so on.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#210592

On Monday 01 July 2019 19:42:08 David Wright wrote:

> On Mon 01 Jul 2019 at 15:56:14 (-0400), Gene Heskett wrote:
> > On Monday 01 July 2019 09:33:35 David Wright wrote:
> > > 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.
> >
> > Whole filesystem encryption would be a total non-starter for me.
>
> Fair enough. Could you reveal why, or are your reasons cryptic too?

No, but if for some reason, say a cerebral accident, I should lose the 
password, the whole system would be locked away, and that would be 
unforgivable.  And at 84&counting, I've no warranty I'll remember my own 
name 10 minutes from my hitting send on this message.

> > File by
> > file with different passwd's according to whats in the file would
> > make far more sense to me. Thats my $0.02.
>
> I can't see how anyone would cope with a scheme like that. How would
> you remember all those passwords?

By limiting it to probably 2.  Normal stuff might just be my user pw, 
whereas stuff that is truly private might have a 2048 bit hash.
>
> OTOH I can see that each file must have an individual encryption key,
> but the encryption scheme looks after generating those. Otherwise
> you would have a large sample of encrypted but known-cleartext files
> available for cracking attempts. (Remember that the filenames are not
> encrypted, and many files on a system will have entirely predictable
> contents, eg much of /usr, your Debian package cache, and so on.

Clearly I haven't explored all the ramifications. Its been more of a case 
of letting my imagination out to play without a chaperone.

> Cheers,
> David.


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>

[toc] | [prev] | [next] | [standalone]

#210865

[Multipart message — attachments visible in raw view] — view raw

On 2/07/19 9:13 PM, Gene Heskett wrote:
> On Monday 01 July 2019 19:42:08 David Wright wrote:
> 
>> On Mon 01 Jul 2019 at 15:56:14 (-0400), Gene Heskett wrote:
>>> On Monday 01 July 2019 09:33:35 David Wright wrote:
>>>> On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:

>>> Whole filesystem encryption would be a total non-starter for me.
>>
>> Fair enough. Could you reveal why, or are your reasons cryptic too?
> 
> No, but if for some reason, say a cerebral accident, I should lose the 
> password, the whole system would be locked away, and that would be 
> unforgivable.  And at 84&counting, I've no warranty I'll remember my own 
> name 10 minutes from my hitting send on this message.

I'm considering whole-filesystem encryption on my laptop, because that's
what's most likely to be lost/stolen etc. But that's backed up to a
machine at home, which is not encrypted.

And you could also put the key on a piece of paper, and lodge it in a
safe deposit box, or with your lawyer, or wherever it needs to be to be
accessible in such unfortunate circumstances.

Richard

[toc] | [prev] | [next] | [standalone]

#210506

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.

[toc] | [prev] | [next] | [standalone]

#210507

On Sun, 2019-06-30 at 18:17 +0200, Sven Hartge wrote:
> Andrea Borgia <andrea@borgia.bo.it> 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

[toc] | [prev] | [next] | [standalone]

#210509

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web