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

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

How could I install ecryptfs-utils on Buster

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

Contents

  How could I install ecryptfs-utils on Buster Pierre Fourès <pierre.foures@gmail.com> - 2019-04-05 17:10 +0200
    Re: How could I install ecryptfs-utils on Buster David Christensen <dpchrist@holgerdanske.com> - 2019-04-05 22:10 +0200
      Re: How could I install ecryptfs-utils on Buster Pierre Fourès <pierre.foures@gmail.com> - 2019-04-10 10:40 +0200
        Re: How could I install ecryptfs-utils on Buster David Christensen <dpchrist@holgerdanske.com> - 2019-04-11 03:00 +0200
          Re: How could I install ecryptfs-utils on Buster Pierre Fourès <pierre.foures@gmail.com> - 2019-04-11 16:00 +0200
            Re: How could I install ecryptfs-utils on Buster David Christensen <dpchrist@holgerdanske.com> - 2019-04-12 06:00 +0200
              Re: How could I install ecryptfs-utils on Buster Celejar <celejar@gmail.com> - 2019-04-16 02:00 +0200
    Re: How could I install ecryptfs-utils on Buster Pierre Fourès <pierre.foures@gmail.com> - 2019-04-10 15:50 +0200
      Re: How could I install ecryptfs-utils on Buster andreimpopescu@gmail.com - 2019-06-10 09:50 +0200

#207032 — How could I install ecryptfs-utils on Buster

Hi,

I'm in the process of rebuilding new virtual instances for the Desktop
user's of my company. We provides these instance in order to be able
to run the validated software stack on non-validated software stacks
(ie. running a virtual box inside a custom installed Linux, or on OSX
or Windows). Theses virtual machines usually ends on laptops. In order
to keep safe the company's data in case of a laptop being stolen, we
set up an encrypted home with ecryptfs-utils.

More over, the install process of Desktop machines is standardized and
shared with bare-metal machines. I install all through deboostrap
(from the validated stack we use on our servers). In order to run the
Desktops, and because of new hardware with video cards not supported
in Stretch, we took the move to Buster a bit earlier an went into the
testing wonderland. This is mostly just a dist-upgrade of the current
validated stack. As a side effect, this helps to pre-validate all our
stack on Buster.

But I just discovered today that ecryptfs-utils is not longer part of
Buster since 2018-12-19. To my understanding, this is due to bug [1]
which perfectly justify the removal of ecryptfs-utils from Buster.
This bug don't really affect our use case scenario as we only target
to protect the data at rest only. I would prefer a bug-free solution,
but we find acceptable to keep on using ecryptfs, especially in
contrast of taking the time to configure something else. I thus
solicit your advice to devise a solution to make it installable again.

I would like a « simple and easy » solution. Here is the options I see :

- Install ecryptfs-utils before proceeding the dist upgrade to buster,
so I have the package installed. But won't Buster removes it, as
feared in [2] ? I have also prepared some virtual instances for our
users and I would prefer not to throw them away to start anew if
possible.

- Builds the virtual instance on Stretch only, not Buster. But I
wouldn't like it much as it would make a split of versions on the
Desktops, and then would add maintenance. More over, user would not be
at ease with different versions of what they use depending if their
are on their bare-metal machine (requiring Buster) or on their virtual
instance (requiring Stretch). Also, with staying on Stretch, when
Buster turn stable stable, then oldstable, how shall I handle the fact
that Stretch will slowly slip in retirement and that Buster as no
alternative, so I can't make the move.

- Install ecryptfs-utils from Sid ? Isn't it risky to take it from Sid
? Especially for such a package.

- Some other approach I not foresee, like maybe add the Stretch
repository in sources.list in order to grab it from there ? It it
feasible ?

I think I would prefer grab the package from Stretch than from Sid.
Both are right now the same versions (as was the version for Buster),
but taking it from Strech would grant me it will not change. I also
prefer not adding the Sid repos in the sources.list. I already was
pretty reticent to made the bump to testing, so to take the plunge to
Sid is way to extreme. Clearly, what would be best would be to proceed
with a Buster already installed system.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765854
[2] https://www.reddit.com/r/debian/comments/asei6c/ecryptfsutils_in_buster/

Regards,
Pierre.

[toc] | [next] | [standalone]

#207050

On 4/5/19 8:07 AM, Pierre Fourès wrote:
> Hi,
> 
> I'm in the process of rebuilding new virtual instances for the Desktop
> user's of my company. We provides these instance in order to be able
> to run the validated software stack on non-validated software stacks
> (ie. running a virtual box inside a custom installed Linux, or on OSX
> or Windows). Theses virtual machines usually ends on laptops. In order
> to keep safe the company's data in case of a laptop being stolen, we
> set up an encrypted home with ecryptfs-utils.
> 
> More over, the install process of Desktop machines is standardized and
> shared with bare-metal machines. I install all through deboostrap
> (from the validated stack we use on our servers). In order to run the
> Desktops, and because of new hardware with video cards not supported
> in Stretch, we took the move to Buster a bit earlier an went into the
> testing wonderland. This is mostly just a dist-upgrade of the current
> validated stack. As a side effect, this helps to pre-validate all our
> stack on Buster.
> 
> But I just discovered today that ecryptfs-utils is not longer part of
> Buster since 2018-12-19. To my understanding, this is due to bug [1]
> which perfectly justify the removal of ecryptfs-utils from Buster.
> This bug don't really affect our use case scenario as we only target
> to protect the data at rest only. I would prefer a bug-free solution,
> but we find acceptable to keep on using ecryptfs, especially in
> contrast of taking the time to configure something else. I thus
> solicit your advice to devise a solution to make it installable again.
> 
> I would like a « simple and easy » solution. Here is the options I see :
> 
> - Install ecryptfs-utils before proceeding the dist upgrade to buster,
> so I have the package installed. But won't Buster removes it, as
> feared in [2] ? I have also prepared some virtual instances for our
> users and I would prefer not to throw them away to start anew if
> possible.
> 
> - Builds the virtual instance on Stretch only, not Buster. But I
> wouldn't like it much as it would make a split of versions on the
> Desktops, and then would add maintenance. More over, user would not be
> at ease with different versions of what they use depending if their
> are on their bare-metal machine (requiring Buster) or on their virtual
> instance (requiring Stretch). Also, with staying on Stretch, when
> Buster turn stable stable, then oldstable, how shall I handle the fact
> that Stretch will slowly slip in retirement and that Buster as no
> alternative, so I can't make the move.
> 
> - Install ecryptfs-utils from Sid ? Isn't it risky to take it from Sid
> ? Especially for such a package.
> 
> - Some other approach I not foresee, like maybe add the Stretch
> repository in sources.list in order to grab it from there ? It it
> feasible ?
> 
> I think I would prefer grab the package from Stretch than from Sid.
> Both are right now the same versions (as was the version for Buster),
> but taking it from Strech would grant me it will not change. I also
> prefer not adding the Sid repos in the sources.list. I already was
> pretty reticent to made the bump to testing, so to take the plunge to
> Sid is way to extreme. Clearly, what would be best would be to proceed
> with a Buster already installed system.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765854
> [2] https://www.reddit.com/r/debian/comments/asei6c/ecryptfsutils_in_buster/
> 
> Regards,
> Pierre.

AFAIK dm-crypt is the canonical disc encryption technology on Linux (see 
crypttab(5) and cryptsetup(8)).  I like the fact that it operates at the 
device level, so everything on an encrypted disc or partition is 
automatically and inescapably encrypted.  File system level encryption, 
such as ecryptfs(7), might make sense for cloud directories or 
sneaker-net media.  I use ccrypt(1) for individual files, but vim(1) has 
an encrypted mode that is very appealing for certain use-cases.


David

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

#207230

Le ven. 5 avr. 2019 à 22:08, David Christensen
<dpchrist@holgerdanske.com> a écrit :
>
> AFAIK dm-crypt is the canonical disc encryption technology on Linux (see
> crypttab(5) and cryptsetup(8)).  I like the fact that it operates at the
> device level, so everything on an encrypted disc or partition is
> automatically and inescapably encrypted.  File system level encryption,
> such as ecryptfs(7), might make sense for cloud directories or
> sneaker-net media.  I use ccrypt(1) for individual files, but vim(1) has
> an encrypted mode that is very appealing for certain use-cases.
>

Indeed, I've planned to give a serious look at it, especially to
encrypt the disks of the servers we rent in remote data-centers, but I
haven't took the time yet for it. And when occurred the requirement to
crypt the virtual machines, I found ecryptfs an easier thing to set
up.

I also found ecryptfs a better fit for my requirements.

Indeed, I like the fact that I, as an administrator, am not able to
access the files of "my" users. I encrypt their home folder then set
the requirement to change the password on their first login (with
'chage -d 0 $user'), might it be their physical desktops or their
virtual instances. Thus I'm sure I won't ever be able to look into
their files without them allowing me. This is known of everybody. This
is a double edged sword. They have to take full responsibility to
backup somewhere their files as I can't help them if anything goes
wrong (and if anything goes wrong I just provide them a new physical
or virtual instance and wipe the problematic one), and at the same
time it is relieving me from the possibility to be able to see
everything everywhere. In a previous company, as not being the system
administrator, I never liked this fact that somebody could access all
files behind all user's backs. I recall one who did that to an user to
look into their personal files (which shouldn't had be there in the
first place, admittedly) and I really disliked the « God mode »
situation offered to system administrators. Now that I administer the
desktops, I went really concerned to lower, by design, my scope of
abilities. I didn't want to rely on my will power and my word of mouth
about this situation. I wanted it to be established by design.
Ciphering user's space with ecryptfs allows me to lock me out very
nicely and easily from this possibility. I haven't found this to be
possible with dm-crypt in an easy and user-friendly way.

Nonetheless, if it's possible to achieve such objective with dm-crypt,
I would really appreciate some pointers about how to do it.

Regards,
Pierre.

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

#207283

On 4/10/19 1:32 AM, Pierre Fourès wrote:
> Le ven. 5 avr. 2019 à 22:08, David Christensen
> <dpchrist@holgerdanske.com> a écrit :
>>
>> AFAIK dm-crypt is the canonical disc encryption technology on Linux (see
>> crypttab(5) and cryptsetup(8)).  I like the fact that it operates at the
>> device level, so everything on an encrypted disc or partition is
>> automatically and inescapably encrypted.  File system level encryption,
>> such as ecryptfs(7), might make sense for cloud directories or
>> sneaker-net media.  I use ccrypt(1) for individual files, but vim(1) has
>> an encrypted mode that is very appealing for certain use-cases.
>>
> 
> Indeed, I've planned to give a serious look at it, especially to
> encrypt the disks of the servers we rent in remote data-centers, but I
> haven't took the time yet for it. And when occurred the requirement to
> crypt the virtual machines, I found ecryptfs an easier thing to set
> up.
> 
> I also found ecryptfs a better fit for my requirements.
> 
> Indeed, I like the fact that I, as an administrator, am not able to
> access the files of "my" users. I encrypt their home folder then set
> the requirement to change the password on their first login (with
> 'chage -d 0 $user'), might it be their physical desktops or their
> virtual instances. Thus I'm sure I won't ever be able to look into
> their files without them allowing me. This is known of everybody. This
> is a double edged sword. They have to take full responsibility to
> backup somewhere their files as I can't help them if anything goes
> wrong (and if anything goes wrong I just provide them a new physical
> or virtual instance and wipe the problematic one), and at the same
> time it is relieving me from the possibility to be able to see
> everything everywhere. In a previous company, as not being the system
> administrator, I never liked this fact that somebody could access all
> files behind all user's backs. I recall one who did that to an user to
> look into their personal files (which shouldn't had be there in the
> first place, admittedly) and I really disliked the « God mode »
> situation offered to system administrators. Now that I administer the
> desktops, I went really concerned to lower, by design, my scope of
> abilities. I didn't want to rely on my will power and my word of mouth
> about this situation. I wanted it to be established by design.
> Ciphering user's space with ecryptfs allows me to lock me out very
> nicely and easily from this possibility. I haven't found this to be
> possible with dm-crypt in an easy and user-friendly way.
> 
> Nonetheless, if it's possible to achieve such objective with dm-crypt,
> I would really appreciate some pointers about how to do it.

How about enfs, gocryptfs, and/or libpam-mount?

2019-04-10 17:48:09 dpchrist@po ~
$ apt-cache search fuse encrypt
afflib-tools - Advanced Forensics Format Library (utilities)
camo - SSL/TLS image proxy to prevent mixed-content warnings
encfs - encrypted virtual filesystem
gocryptfs - Encrypted overlay filesystem written in Go.
libpam-mount - PAM module that can mount volumes for a user session


David

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

#207311

Le jeu. 11 avr. 2019 à 02:52, David Christensen
<dpchrist@holgerdanske.com> a écrit :
>
> On 4/10/19 1:32 AM, Pierre Fourès wrote:
> > Le ven. 5 avr. 2019 à 22:08, David Christensen
> > <dpchrist@holgerdanske.com> a écrit :
> >>
> >> AFAIK dm-crypt is the canonical disc encryption technology on Linux (see
> >> crypttab(5) and cryptsetup(8)).  I like the fact that it operates at the
> >> device level, so everything on an encrypted disc or partition is
> >> automatically and inescapably encrypted.  File system level encryption,
> >> such as ecryptfs(7), might make sense for cloud directories or
> >> sneaker-net media.  I use ccrypt(1) for individual files, but vim(1) has
> >> an encrypted mode that is very appealing for certain use-cases.
> >>
> >
> > Indeed, I've planned to give a serious look at it, especially to
> > encrypt the disks of the servers we rent in remote data-centers, but I
> > haven't took the time yet for it. And when occurred the requirement to
> > crypt the virtual machines, I found ecryptfs an easier thing to set
> > up.
> >
> > I also found ecryptfs a better fit for my requirements.
> >
> > Indeed, I like the fact that I, as an administrator, am not able to
> > access the files of "my" users. I encrypt their home folder then set
> > the requirement to change the password on their first login (with
> > 'chage -d 0 $user'), might it be their physical desktops or their
> > virtual instances. Thus I'm sure I won't ever be able to look into
> > their files without them allowing me. This is known of everybody. This
> > is a double edged sword. They have to take full responsibility to
> > backup somewhere their files as I can't help them if anything goes
> > wrong (and if anything goes wrong I just provide them a new physical
> > or virtual instance and wipe the problematic one), and at the same
> > time it is relieving me from the possibility to be able to see
> > everything everywhere. In a previous company, as not being the system
> > administrator, I never liked this fact that somebody could access all
> > files behind all user's backs. I recall one who did that to an user to
> > look into their personal files (which shouldn't had be there in the
> > first place, admittedly) and I really disliked the « God mode »
> > situation offered to system administrators. Now that I administer the
> > desktops, I went really concerned to lower, by design, my scope of
> > abilities. I didn't want to rely on my will power and my word of mouth
> > about this situation. I wanted it to be established by design.
> > Ciphering user's space with ecryptfs allows me to lock me out very
> > nicely and easily from this possibility. I haven't found this to be
> > possible with dm-crypt in an easy and user-friendly way.
> >
> > Nonetheless, if it's possible to achieve such objective with dm-crypt,
> > I would really appreciate some pointers about how to do it.
>
> How about enfs, gocryptfs, and/or libpam-mount?
>
> 2019-04-10 17:48:09 dpchrist@po ~
> $ apt-cache search fuse encrypt
> afflib-tools - Advanced Forensics Format Library (utilities)
> camo - SSL/TLS image proxy to prevent mixed-content warnings
> encfs - encrypted virtual filesystem
> gocryptfs - Encrypted overlay filesystem written in Go.
> libpam-mount - PAM module that can mount volumes for a user session
>
>
> David
>

Thanks David for the pointers.

I gave a look at them and this open viables alternatives to ecryptfs,
would I require to go away from it doesn't get reintegrated in Debian.
This drove me to gave a look to see if ecryptfs is still actively
maintained and it seems to be the case as the last commit dates from
2019-02-16 [1]. The package is also announced in [2] as heavily used
in Ubuntu, ChromeOS and several NAS products, so I hope the bug will
get fixed. If it doesn't, to what I saw in [3], gocryptfs seems really
promising, however I find it still a little young for this kind of
subject (2015 for it first release). As I plan to configure dm-crypt
for our servers, I will first dig deeper on the libpam-mount
opportunity. This could make a good fit to satisfy all my use-cases
while only using the same base ciphering tool. So for now, I will keep
ecryptfs running on the desktops in the next following months and will
first start to setup full disk encryption on the servers, then will I
look back to what to do with the desktops.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs.git/log/fs/ecryptfs?h=next
[2] http://ecryptfs.org/about.html
[3] https://nuetzlich.net/gocryptfs/comparison/

Regards,
Pierre.

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

#207351

On 4/11/19 6:51 AM, Pierre Fourès wrote:
> Le jeu. 11 avr. 2019 à 02:52, David Christensen
> <dpchrist@holgerdanske.com> a écrit :
>> How about enfs, gocryptfs, and/or libpam-mount?
>>
>> 2019-04-10 17:48:09 dpchrist@po ~
>> $ apt-cache search fuse encrypt
>> afflib-tools - Advanced Forensics Format Library (utilities)
>> camo - SSL/TLS image proxy to prevent mixed-content warnings
>> encfs - encrypted virtual filesystem
>> gocryptfs - Encrypted overlay filesystem written in Go.
>> libpam-mount - PAM module that can mount volumes for a user session
> 
> Thanks David for the pointers.
> 
> I gave a look at them and this open viables alternatives to ecryptfs,
> would I require to go away from it doesn't get reintegrated in Debian.
> This drove me to gave a look to see if ecryptfs is still actively
> maintained and it seems to be the case as the last commit dates from
> 2019-02-16 [1]. The package is also announced in [2] as heavily used
> in Ubuntu, ChromeOS and several NAS products, so I hope the bug will
> get fixed. If it doesn't, to what I saw in [3], gocryptfs seems really
> promising, however I find it still a little young for this kind of
> subject (2015 for it first release). As I plan to configure dm-crypt
> for our servers, I will first dig deeper on the libpam-mount
> opportunity. This could make a good fit to satisfy all my use-cases
> while only using the same base ciphering tool. So for now, I will keep
> ecryptfs running on the desktops in the next following months and will
> first start to setup full disk encryption on the servers, then will I
> look back to what to do with the desktops.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs.git/log/fs/ecryptfs?h=next
> [2] http://ecryptfs.org/about.html
> [3] https://nuetzlich.net/gocryptfs/comparison/


Understand that each encryption solution -- dm-crypt, encfs, etc. -- 
provides protection against some limited threat; I have not found one 
that works for all use-cases.


dm-crypt is designed to protect encrypted discs when they are at rest 
(cold) -- e.g. the computer is stolen while powered down, the encrypted 
disc has been removed from a computer, etc..  Once a dm-crypt disc is 
decrypted and operating, the system sees a mapped device node (which 
will typically contain a plaintext file system).  Traditional Unix 
permissions apply -- e.g. root can see everything, other users can see 
whatever their UID's/GID's allow per file and directory ownership, mode, 
extended attributes, etc..


If I remember encfs correctly, encfs is designed to provide exclusive 
access to the user who mounts an encrypted folder -- no other user, 
including root, can see the plaintext.


David

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

#207526

On Thu, 11 Apr 2019 20:56:04 -0700
David Christensen <dpchrist@holgerdanske.com> wrote:

...

> If I remember encfs correctly, encfs is designed to provide exclusive 
> access to the user who mounts an encrypted folder -- no other user, 
> including root, can see the plaintext.

My understanding is that while this is technically correct, it must be
understood that any protection against a malicious root user is
nevertheless mostly illusory, since root can simply do 'su
username' (not to mention run a password sniffer, or directly examine
kernel data structures, bypassing the filesystem):

https://unix.stackexchange.com/questions/94170/use-encfs-to-encrypt-files-so-that-a-particular-user-or-process-can-access-them
https://unix.stackexchange.com/questions/47018/encfs-with-expect-access-denied
https://www.linuxquestions.org/questions/linux-security-4/can-i-protect-against-root-592947/
https://askubuntu.com/questions/316197/password-protect-files-folders-using-cli

Celejar

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

#207243

Le ven. 5 avr. 2019 à 17:07, Pierre Fourès <pierre.foures@gmail.com> a écrit :
> I would like a « simple and easy » solution.

In the hope it may help someone or at least give some food for
thoughts, here is what I eventually did to fix my issue.

I use apt-cacher-ng. I first thought to log in the instance and grab
the package and install it manually via dpkg (and do this with all it
dependencies). My point was to revert back to what buster was before
the removal of this package. However, the versions of package
ecryptfs-utils are currently the same between stretch, buster and sid.
So the .deb file will stay in the pool of the mirrors at least until
debian stretch goes out from the LTS it hasn't entered yet. This is a
long time frame. I then thought to use a combo of wget and dpkg to
install it straight from the pool. I also identified this package
could also be removed from the pool if this package is updated in
debian stretch while still in the stable life-cycle of stretch and
included in a point release. There is not a big time-frame for it, and
if this would happen, I believe ecrypfs-utils would probably be
reintegrated in buster-backports. I then take the bet that it won't be
updated before stretch goes oldstable (which should only be some
months ahead) or if it is, ecryptfs should appears in
buster-backports. If not, I will have to find an other solution.

With that being said, I devised my solution relying on the fact that
ecryptfs utils will stay in stretch in order to stay in the pool. But,
instead of fiddling with wget and dpkg, wouldn't it be more efficient
to use the power of apt to install it and all of its dependencies ? I
went back to my idea to use the repository of stretch into the
instance of buster. With the rules of precedence set in apt, I
(almost) never can be able to mix my distrib with software from
stretch. The problem is sensible when mixing with forward versions of
Debian, but, to my understanding, can't occur when mixing with
backward versions of Debian. Please, correct me if I'm wrong.

If I use apt, it will look for the most recent version and take
precedence on the version of buster. But if it appears a package isn't
in the buster repository (like ecryptfs-utils), it might find it in
the stretch repository, and install it from there. While doing so, it
will look for the dependencies and install all of them. But while
looking to satisfy the dependencies, it will find them in the buster
repository and install the most recent of them. I'm then granted I
won't have an installation who slowly slip toward not being 100%
buster except one package or so.

I did the test and all went as expected. I got ecryptfs-utils being
installed with the four of its dependencies. One of them, keyutils, is
in 1.5.9-9 in stretch and 1.6.6 in buster. As expected, apt installed
the one from buster. After the install, I then had precisely the same
packages installed in the same versions as what it was before
ecryptfs-utils was removed from buster. This kind of satisfy my «
simple and easy » solution requirement.

I just have one minor consideration about this. It was about adding
stretch-security on top of it. In the case ecryptfs would be updated,
I would like to take this upgrade. But I'm not sure this would play
well regarding other packages being in the same version number between
stretch and buster. Thinking when stretch will be in LTS, a package
could get an update earlier in stretch than in buster. The package
would then be installed from the stretch-security updates instead of
the pending one in buster. Then when the buster package get released,
how would this all converge ? I'm not sure how all this would goes,
and I'm not willing to experiment, so I decided to leave off the
stretch-security repository and just use the buster one. Doing so,
only ecryptfs-utils (and its companion lib) won't get any security
updates. I will then manually look for updates on ecryptfs package and
decide what to do from there. I indeed subscribed to bug #765854 and
also to the tracker for package ecryptfs-utils for this purpose. I
will be notified by email if anything moves there before it hit the
repositories. If this would ever would happen, I guess I will have to
adjust this current fix for this situation. A simple update wouldn't
seem to be wise without more careful inspection of the situation. Thus
I guess I'm not loosing much on not having ecrypfs automatically
handled by security updates.

I hope I didn't missed anything who could jeopardize the situation,
but I'm pretty confident with all this, and happy how it turned out.
Indeed, I just added two lines before the 'apt-get install
ecryptfs-utils' command, here they are, simple and easy :

> echo "deb http://http.debian.net/debian/ stretch main contrib" >> /etc/apt/sources.list
> apt-get update

Off course, I very welcome comments on all this if I overlooked something.

Regards,
Pierre.

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

#209787

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

On Mi, 10 apr 19, 15:40:13, Pierre Fourès wrote:
> 
> I did the test and all went as expected. I got ecryptfs-utils being
> installed with the four of its dependencies. One of them, keyutils, is
> in 1.5.9-9 in stretch and 1.6.6 in buster. As expected, apt installed
> the one from buster. After the install, I then had precisely the same
> packages installed in the same versions as what it was before
> ecryptfs-utils was removed from buster. This kind of satisfy my «
> simple and easy » solution requirement.

Your solution (mix stretch with buster) is pretty safe.

Just for your peace of mind, you could provide additional hints to APT 
like setting Default-Release to "buster".
 
> I just have one minor consideration about this. It was about adding
> stretch-security on top of it. In the case ecryptfs would be updated,
> I would like to take this upgrade. But I'm not sure this would play
> well regarding other packages being in the same version number between
> stretch and buster. 

Version numbers in release-security are specifically chosen to "play 
nice" with version numbers in release+1 (otherwise full/dist-upgrades 
wouldn't work), so updating from stretch-security should be safe, even 
more so with the Default-Release setting proposed above.

As an additional safeguard you could also use pinning to tell APT that 
you only want encryptfs (and dependencies) from stretch (priority 100), 
and pin the rest of stretch to a lower priority (e.g. 1).

One other possibility that I didn't see mentioned in this thread would 
be to make a forward port to buster of the stretch encryptfs package in 
case buster diverges too much from stretch and makes it uninstallable.

Considering that buster is in deep freeze the probability for this to 
happen is quite low though.


Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

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

csiph-web