[dm-crypt] cryptsetup 2.4.0 does not compile on musl libc anymore

[dm-crypt] cryptsetup 2.4.0 does not compile on musl libc anymore

[Sören Tempel]

Hello,

I just wanted to let you know that cryptsetup 2.4.0, contrary to 2.3.0,
no longer compiles with musl libc, e.g. as used on Alpine Linux, by
default. This is due to the fact that the external tokens code uses
dlvsym(3) which is a GNU extension not supported by musl. However, even
if support for external tokens is disabled (--disable-external-tokens)
`tests/all-symbols-test.c` fails to compile as it also requires dlvsym
and is not compiled conditionally.

Please CC me, I am not subscribed to the list.

Greetings,
Sören
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: cryptsetup 2.4.0 does not compile on musl libc anymore

[Milan Broz]

On 8/18/21 7:56 PM, Sören Tempel wrote:
> Hello,
> 
> I just wanted to let you know that cryptsetup 2.4.0, contrary to 2.3.0,
> no longer compiles with musl libc, e.g. as used on Alpine Linux, by
> default. This is due to the fact that the external tokens code uses
> dlvsym(3) which is a GNU extension not supported by musl. However, even
> if support for external tokens is disabled (--disable-external-tokens)
> `tests/all-symbols-test.c` fails to compile as it also requires dlvsym
> and is not compiled conditionally.

Hi,

Please create an issue in upstream project
https://gitlab.com/cryptsetup/cryptsetup/-/issues/new

The dlvsym() is crucial to the LUKS2 external token extension, so perhaps
the only solution would be to compile without external tokens for these
constrained libc systems.

And please, report this sooner - we released release-candidates exactly
to find such problems.
But people still do the same - waiting for final release, then complain
that something is broken. We cannot fix things that we do not know about.

If we can somehow automate build with non-glibc systems, I can add this
to CI later.

Thanks,
Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: cryptsetup 2.4.0 does not compile on musl libc anymore

[Sören Tempel]

Milan Broz <gmazyland@gmail.com> wrote:
> Please create an issue in upstream project
> https://gitlab.com/cryptsetup/cryptsetup/-/issues/new

Sorry, I don't have a gitlab.com account.

> The dlvsym() is crucial to the LUKS2 external token extension, so perhaps
> the only solution would be to compile without external tokens for these
> constrained libc systems.

Only dlvsym is a GNU extension, dlsym itself is mandated by POSIX.1-2008
and as such also available on musl libc. I haven't looked at the
cryptsetup implementation in detail, but maybe dlsym can be used as a
fallback if __GLIBC__ is not defined?

Compiling with --disable-external-tokens is also fine for now, the main
issue is the all-symbols-test since it is compiled unconditionally.

> And please, report this sooner - we released release-candidates
> exactly to find such problems.  But people still do the same - waiting
> for final release, then complain that something is broken. We cannot
> fix things that we do not know about.

I am sorry, I don't always have the time to test release candidates.
Also: I am not complaining just wanted to inform you about this.

Greetings,
Sören
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: cryptsetup 2.4.0 does not compile on musl libc anymore

[Milan Broz]

On 8/20/21 1:48 PM, Sören Tempel wrote:
> Milan Broz <gmazyland@gmail.com> wrote:
>> Please create an issue in upstream project
>> https://gitlab.com/cryptsetup/cryptsetup/-/issues/new
> 
> Sorry, I don't have a gitlab.com account.

ok, just it is always better to have discussion there,
also you get mail ince it is fixed in git.
(And this list apparently keep some replies in moderation queue...)

>> The dlvsym() is crucial to the LUKS2 external token extension, so perhaps
>> the only solution would be to compile without external tokens for these
>> constrained libc systems.
> 
> Only dlvsym is a GNU extension, dlsym itself is mandated by POSIX.1-2008
> and as such also available on musl libc. I haven't looked at the
> cryptsetup implementation in detail, but maybe dlsym can be used as a
> fallback if __GLIBC__ is not defined?

We discussed that and seems there are different opinions if it should
be supported. We have very strict requirements what plugin exports
and there is possibility that API will change in future.
(A plugin providing both versions of functions then risks musl
loads the wrong version.)
> Compiling with --disable-external-tokens is also fine for now, the main
> issue is the all-symbols-test since it is compiled unconditionally.

Yes, this is easy to fix (by skipping the test if that API is not available).

>> And please, report this sooner - we released release-candidates
>> exactly to find such problems.  But people still do the same - waiting
>> for final release, then complain that something is broken. We cannot
>> fix things that we do not know about.
> 
> I am sorry, I don't always have the time to test release candidates.
> Also: I am not complaining just wanted to inform you about this.

Sorry, I did not want to be rude. Just it happens every time, that the day
after release we get a report that is trivial to fix before final version
- just if we know about it :-)

Thanks,
Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: cryptsetup 2.4.0 does not compile on musl libc anymore

[Milan Broz]

Just FYI, if anyone want to test musl (and embedded distros based on that),
there are few fixes in
https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/207

Thanks,
Milan


On 8/20/21 2:11 PM, Milan Broz wrote:
> On 8/20/21 1:48 PM, Sören Tempel wrote:
>> Milan Broz <gmazyland@gmail.com> wrote:
>>> Please create an issue in upstream project
>>> https://gitlab.com/cryptsetup/cryptsetup/-/issues/new
>>
>> Sorry, I don't have a gitlab.com account.
> 
> ok, just it is always better to have discussion there,
> also you get mail ince it is fixed in git.
> (And this list apparently keep some replies in moderation queue...)
> 
>>> The dlvsym() is crucial to the LUKS2 external token extension, so perhaps
>>> the only solution would be to compile without external tokens for these
>>> constrained libc systems.
>>
>> Only dlvsym is a GNU extension, dlsym itself is mandated by POSIX.1-2008
>> and as such also available on musl libc. I haven't looked at the
>> cryptsetup implementation in detail, but maybe dlsym can be used as a
>> fallback if __GLIBC__ is not defined?
> 
> We discussed that and seems there are different opinions if it should
> be supported. We have very strict requirements what plugin exports
> and there is possibility that API will change in future.
> (A plugin providing both versions of functions then risks musl
> loads the wrong version.)
>> Compiling with --disable-external-tokens is also fine for now, the main
>> issue is the all-symbols-test since it is compiled unconditionally.
> 
> Yes, this is easy to fix (by skipping the test if that API is not available).
> 
>>> And please, report this sooner - we released release-candidates
>>> exactly to find such problems.  But people still do the same - waiting
>>> for final release, then complain that something is broken. We cannot
>>> fix things that we do not know about.
>>
>> I am sorry, I don't always have the time to test release candidates.
>> Also: I am not complaining just wanted to inform you about this.
> 
> Sorry, I did not want to be rude. Just it happens every time, that the day
> after release we get a report that is trivial to fix before final version
> - just if we know about it :-)
> 
> Thanks,
> Milan
> 

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de