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

Groups > linux.debian.bugs.dist > #1015794 > unrolled thread

Bug#951048: util-linux: please build with dm-verity support when uploading 2.35

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#951048: util-linux: please build with dm-verity support when uploading 2.35 Michael Biebl <biebl@debian.org> - 2020-06-29 20:20 +0200
    Bug#951048: util-linux: please build with dm-verity support when uploading 2.35 Luca Boccassi <bluca@debian.org> - 2020-06-30 10:40 +0200
      Bug#951048: util-linux: please build with dm-verity support when uploading 2.35 Luca Boccassi <bluca@debian.org> - 2020-07-24 15:20 +0200
        Bug#951048: util-linux: please build with dm-verity support when uploading 2.35 Chris Hofstaedtler <zeha@debian.org> - 2020-07-24 15:30 +0200
          Bug#951048: util-linux: please build with dm-verity support when uploading 2.35 Luca Boccassi <bluca@debian.org> - 2020-07-24 15:40 +0200
            Bug#951048: util-linux: please build with dm-verity support when uploading 2.35 Luca Boccassi <bluca@debian.org> - 2020-07-30 11:30 +0200

#1015794 — Bug#951048: util-linux: please build with dm-verity support when uploading 2.35

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

Hi Luca

On Mon, 29 Jun 2020 12:16:39 +0100 Luca Boccassi <bluca@debian.org> wrote:
> On Mon, 2020-06-29 at 12:58 +0200, Michael Biebl wrote:
> > Am 29.06.20 um 12:41 schrieb Luca Boccassi:
> > > In terms of image size, what % does that additional 5.6MB represent?
> > 
> > A minbase debootstrap of bullseye is currently 197M
> 
> Thanks - so about ~2.5%. I can look into changing to dlopen as you
> suggested in the next few days.

I see that Simon has been very active in tracking down and informing all
affected upstreams and trying to get them on board in fixing this in a
coordinated fashion.

As far as libmount is concerned, I think going the upstream route is
definitely the right approach. We shouldn't do this downstream. Let's
see what Karel has to say.
Btw, thanks for the offer to look into this.

Regards,
Michael

[toc] | [next] | [standalone]

#1015856

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

On Mon, 2020-06-29 at 20:11 +0200, Michael Biebl wrote:
> Hi Luca
> 
> On Mon, 29 Jun 2020 12:16:39 +0100 Luca Boccassi <bluca@debian.org> wrote:
> > On Mon, 2020-06-29 at 12:58 +0200, Michael Biebl wrote:
> > > Am 29.06.20 um 12:41 schrieb Luca Boccassi:
> > > > In terms of image size, what % does that additional 5.6MB represent?
> > > 
> > > A minbase debootstrap of bullseye is currently 197M
> > 
> > Thanks - so about ~2.5%. I can look into changing to dlopen as you
> > suggested in the next few days.
> 
> I see that Simon has been very active in tracking down and informing all
> affected upstreams and trying to get them on board in fixing this in a
> coordinated fashion.
> 
> As far as libmount is concerned, I think going the upstream route is
> definitely the right approach. We shouldn't do this downstream. Let's
> see what Karel has to say.
> Btw, thanks for the offer to look into this.
> 
> Regards,
> Michael

PR opened at https://github.com/karelzak/util-linux/pull/1084

-- 
Kind regards,
Luca Boccassi

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

#1019132

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

Control: tags -1 patch

On Tue, 30 Jun 2020 09:30:34 +0100 Luca Boccassi <bluca@debian.org> wrote:
> On Mon, 2020-06-29 at 20:11 +0200, Michael Biebl wrote:
> > Hi Luca
> > 
> > On Mon, 29 Jun 2020 12:16:39 +0100 Luca Boccassi <bluca@debian.org> wrote:
> > > On Mon, 2020-06-29 at 12:58 +0200, Michael Biebl wrote:
> > > > Am 29.06.20 um 12:41 schrieb Luca Boccassi:
> > > > > In terms of image size, what % does that additional 5.6MB represent?
> > > > 
> > > > A minbase debootstrap of bullseye is currently 197M
> > > 
> > > Thanks - so about ~2.5%. I can look into changing to dlopen as you
> > > suggested in the next few days.
> > 
> > I see that Simon has been very active in tracking down and informing all
> > affected upstreams and trying to get them on board in fixing this in a
> > coordinated fashion.
> > 
> > As far as libmount is concerned, I think going the upstream route is
> > definitely the right approach. We shouldn't do this downstream. Let's
> > see what Karel has to say.
> > Btw, thanks for the offer to look into this.
> > 
> > Regards,
> > Michael
> 
> PR opened at https://github.com/karelzak/util-linux/pull/1084

PR for dlopen() has been merged and it's part of the 2.36 release which
was just uploaded to unstable, so opened another MR to enable it again
(in dlopen mode):

https://salsa.debian.org/debian/util-linux/-/merge_requests/16

Built locally and confirmed there's no linkage, and thus no dependency,
and strace shows libcryptsetup is only loaded if one of the verity
options is requested, so there should not be any conflict in the
future.

-- 
Kind regards,
Luca Boccassi

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

#1019133

Luca, Helmut, everyone reading at home,

* Luca Boccassi <bluca@debian.org> [200724 15:11]:
> > PR opened at https://github.com/karelzak/util-linux/pull/1084
> 
> PR for dlopen() has been merged and it's part of the 2.36 release which
> was just uploaded to unstable, so opened another MR to enable it again
> (in dlopen mode):
> 
> https://salsa.debian.org/debian/util-linux/-/merge_requests/16
> 
> Built locally and confirmed there's no linkage, and thus no dependency,
> and strace shows libcryptsetup is only loaded if one of the verity
> options is requested, so there should not be any conflict in the
> future.

Okay, I see the PR.

However:

1) Helmut, will this cause problems again for bootstrapping or is
this fine?

2) What exactly are we doing this for? What is the usecase for
Debian?

Chris

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

#1019136

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

On Fri, 2020-07-24 at 15:19 +0200, Chris Hofstaedtler wrote:
> Luca, Helmut, everyone reading at home,
> 
> * Luca Boccassi <bluca@debian.org> [200724 15:11]:
> > > PR opened at https://github.com/karelzak/util-linux/pull/1084
> > 
> > PR for dlopen() has been merged and it's part of the 2.36 release which
> > was just uploaded to unstable, so opened another MR to enable it again
> > (in dlopen mode):
> > 
> > https://salsa.debian.org/debian/util-linux/-/merge_requests/16
> > 
> > Built locally and confirmed there's no linkage, and thus no dependency,
> > and strace shows libcryptsetup is only loaded if one of the verity
> > options is requested, so there should not be any conflict in the
> > future.
> 
> Okay, I see the PR.
> 
> However:
> 
> 1) Helmut, will this cause problems again for bootstrapping or is
> this fine?
> 
> 2) What exactly are we doing this for? What is the usecase for
> Debian?

1) Helmut should double-check, but there's no runtime dependency of any
kind (-dev package, pkg-config, linking) and the build-dep is marked as
!stage1, so should all be good on that front as far as I can tell

2) it's an end-user feature for anybody (myself being one) wanting to
use verity-protected volumes (integrity checks, possible signature
checks) on their machines 
https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity

-- 
Kind regards,
Luca Boccassi

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

#1019768

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

On Fri, 24 Jul 2020 14:37:36 +0100 Luca Boccassi <bluca@debian.org> wrote:
> On Fri, 2020-07-24 at 15:19 +0200, Chris Hofstaedtler wrote:
> > Luca, Helmut, everyone reading at home,
> > 
> > * Luca Boccassi <bluca@debian.org> [200724 15:11]:
> > > > PR opened at https://github.com/karelzak/util-linux/pull/1084
> > > 
> > > PR for dlopen() has been merged and it's part of the 2.36 release which
> > > was just uploaded to unstable, so opened another MR to enable it again
> > > (in dlopen mode):
> > > 
> > > https://salsa.debian.org/debian/util-linux/-/merge_requests/16
> > > 
> > > Built locally and confirmed there's no linkage, and thus no dependency,
> > > and strace shows libcryptsetup is only loaded if one of the verity
> > > options is requested, so there should not be any conflict in the
> > > future.
> > 
> > Okay, I see the PR.
> > 
> > However:
> > 
> > 1) Helmut, will this cause problems again for bootstrapping or is
> > this fine?
> > 
> > 2) What exactly are we doing this for? What is the usecase for
> > Debian?
> 
> 1) Helmut should double-check, but there's no runtime dependency of any
> kind (-dev package, pkg-config, linking) and the build-dep is marked as
> !stage1, so should all be good on that front as far as I can tell
> 
> 2) it's an end-user feature for anybody (myself being one) wanting to
> use verity-protected volumes (integrity checks, possible signature
> checks) on their machines 
> https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html
> https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity

Hello Chris,

Helmut reviewed and approved the MR (thanks!)[0], anything else left to do for this?

Thank you!

-- 
Kind regards,
Luca Boccassi

[0] https://salsa.debian.org/debian/util-linux/-/merge_requests/16#note_183169

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web