would need to compute
1/sqrt(x). Ending up with an exact copy of the Doom implementation really isn’t
great from a copyright and license compliance point of view.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedora
c key
needs to have limited permissions.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedorapr
nel on its own.
If you want to do that, the simplest way is probably to just `dnf reinstall`
the kernel. Alternatively, invoking /usr/bin/kernel-install with the right
parameters will run this scriptlet, and also re-generate the rescue kernel.
HTH,
Clemens
--
Clemens Lang
RHEL Crypto Team
Red Ha
lly disable them.
I suspect a bunch of other entries on that list are in the same position.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraprojec
the better. At best, you’re buying yourself a year by rejecting
this change.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora C
nd string handling. I have a hacky patch at [1] that fixes it,
but it should really be reported to Python so it can be fixed upstream. From
what I recall, there was no way to fix this in livicd-creator.
[1]: https://github.com/neverpanic/qubip-live-image/blob/main/urllib.patch
--
Clemens
view, all that libxcrypt is doing is essentially
equivalent to a base64encode(), and FIPS doesn’t care (*).
*) this is not legal advice, I am not a lawyer, do your own research
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailin
t yet provide a stable interface.
[1]: https://access.redhat.com/articles/rhel9-abi-compatibility
[2]:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/package_manifest/index#application_streams
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
__
Hi,
> On 18. Dec 2024, at 17:51, Fabio Valentini wrote:
>
> On Wed, Dec 18, 2024 at 10:43 AM Clemens Lang wrote:
>>
>> See https://src.fedoraproject.org/rpms/stunnel, or
>> https://src.fedoraproject.org/rpms/gnutls, owned by @crypto-team.
>
> Looks like th
maintainer is currently out of office.
As a consequence, I am very much opposed to a rule that would require packages
to be maintained by single individuals. Are there such cases as you describe?
Absolutely! Should they be a reason to completely ban groups? No.
--
ke it part of the change proposal right now.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.
ore strict crypto-policy, the next
run would remove (or propose to remove) keys that are no longer considered
secure under that crypto-policy?
Thanks,
Clemens
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedorap
SSDs, and does not come with the Zig
dependency.
I’ve been using that for quite a while now and I don’t miss ncdu at all.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an e
Hi Michael,
> On 20. Nov 2024, at 15:52, Michael Catanzaro wrote:
>
> On Wed, Nov 20 2024 at 11:09:05 AM +01:00:00, Clemens Lang
> wrote:
>> The idea here was to auto-enable pkcs11-provider when it is installed, which
>> still makes sense to me. The issue here I t
it is installed, which
still makes sense to me. The issue here I think is that many people ended up
with pkcs11-provider installed because of a recommendation. We should remove
that recommendation, most users don’t need pcks11-provider installed.
HTH,
Clemens
--
C
replied already… would you mind doing a package review
for it at https://bugzilla.redhat.com/show_bug.cgi?id=2315641? I just learned
that that’s required since the package has been orphaned for more than 8 weeks.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
]:
https://copr.fedorainfracloud.org/coprs/logic/dovecot-fts-xapian/package/dovecot-fts-xapian/
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
uch in the middle of doing the required NSS
rebase in Fedora, CentOS Stream, and RHEL.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproj
Hi,
> On 23. Jul 2024, at 16:36, Gary Buhrmaster wrote:
>
> On Tue, Jul 23, 2024 at 8:55 AM Clemens Lang wrote:
>
>> However, we should still consider the effect this will have on developers
>> that build software on Fedora — they will also have to specify
>>
d software on Fedora — they will also have to specify -DOPENSSL_NO_ENGINE
now or see failing builds, and we don’t really see that impact until 41
releases.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedorapr
Hi,
> On 22. Jul 2024, at 16:32, Fabio Valentini wrote:
>
> On Mon, Jul 22, 2024 at 4:28 PM Clemens Lang wrote:
>>
>> Hi Neal,
>>
>>
>>> On 22. Jul 2024, at 15:01, Neal Gompa wrote:
>>>
>>> The CentOS approach isn't a de
pening, then there's no way to support removing the
> engine API from Fedora's OpenSSL.
We’re happy to help maintainers that want to do this. We may do it ourselves
for selected components. We will not fix every single use ourselves.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
__
now whether there would be any specific other Fedora process we would
have to follow — maybe others can chime in on this.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
ll packages using
> ENGINE_cleanup and tell them to decide whether to BuildRequires:
> openssl-devel-engine.
Correct, I just didn’t have the time to work on this yet.
See https://bugzilla.redhat.com/show_bug.cgi?id=2296114 for some progress
towards this.
If anybody has automated tooling to
applications can be written
in a way that they don’t care whether the private key is in a file or a
smartcard. ENGINEs also use various differing code paths inside of OpenSSL,
which often trigger subtle bugs and weird behavior.
HTH,
Clemens
--
Clemens Lang
RHEL
include
> # endif
>
> +#if ! __has_include()
> +# define OPENSSL_NO_ENGINE
> +#endif
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
That’s one potential way, thanks for the patch – however, it has the same
fail-silent problem.
--
Clemens Lang
RHEL Crypt
to
make such things configurable.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en
Hi,
> On 5. Jul 2024, at 14:49, Daniel P. Berrangé wrote:
>
> On Fri, Jul 05, 2024 at 02:37:41PM +0200, Clemens Lang wrote:
>>
>>
>> Please start addressing this with whoever maintains the TPM specification.
>
> The TPM spec is maintained by the Trusted
nly have to add BuildRequires:
openssl-devel-engine instead of adding a preprocessor define.
It also has the same downside of silently disabling engines if the maintainer
doesn’t check.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
__
mode.
You should really use a separate openssl configuration file using OPENSSL_CONF
instead, and start a discussion to get the TPM standard updated.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.
her is fail-silent with work for maintainers that
want to continue using engines. Which ones is better?
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le..
Rich.
>
> Anyway, -1 from me, too
>
> For exactly that reason.
Can you elaborate what you would need, in addition to the LEGACY policy (which
still allows these connections) and the runcp utility?
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
__
to the legacy machines, while maintaining general system
> security.
See this text in the proposal (emphasis mine):
Users that need the previous behaviour and don't mind the security implications
will be able to revert to the old behavior system-wide (update-crypto-policies
--set FEDORA4
bout
post-quantum cryptographic signature algorithms soon, otherwise we’ll end up
having the same discussion again in 10 years, when TLS and many other common
protocols have moved.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
___
dev
1] uses the OpenPGP packet format, which can (and in
practice likely does) contain a different hash of the signed content, over
which it creates a signature, so even commits with a SHA-1 commit ID can be
signed in a fashion that will continue to validate with this change.
--
Clem
e other eventually. I suspect if Fedora
decides to keep ENGINE support, we’ll have the exact same discussion in a few
years when OpenSSL 4.0 is released, and people will demand that the rebase to
4.0 that removes engine support should be a system-wide change proposal because
it breaks engi
example https://github.com/latchset/pkcs11-provider/pull/328, which
allows the PKCS11 provider to work everywhere where a simple PEM private key
file is currently supported. With this, the Ruby OpenSSL module has all the
time in the world to make the transition.
--
Clemens La
ump *already* exists between
different builds of OpenSSL with different configuration.
[1]: https://github.com/openssl/openssl/blob/master/util/libssl.num
[2]: https://github.com/openssl/openssl/blob/master/util/libcrypto.num
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
__
is that the host was
not already able to do these things.
If you don’t trust your host, look into confidential computing and confidential
containers. Those also don’t solve every single problem, but they get you
closer.
--
Clemens Lang
RHEL Crypto Team
Red Hat
--
_
t there, is it possible that evolution runs with a
seccomp filter or other BPF program configured to kill the process on
violation, and that’s what’s happening here?
For software that regularly deals with untrusted input, it doesn’t seem
unreasonable that the developers might have implemented somethin
out this.
I think the importer should be modified to attempt to import all keys in a file
and ignore those that fail.
The other alternative is that all keys should be imported regardless of whether
they will be considered usable for verification, and verification of RPMs will
later fail if tho
use the community
as guinea pigs; we ourselves were surprised by the fallout, and have been
working internally with the maintainers of our signing keys to get this
resolved. That work is still ongoing, but we will probably delay disabling
SHA-1 in PGP use until CentOS Stream 10/RHEL 10.
--
Steve Dickson wrote:
I'm trying to access kernel.org with kup
script but it does not seem to be in Fedora 37.
The only rpm I can find is kup-0.3.6-11.fc36.rpm.
What am I missing??
The package has been orphaned and retired:
https://src.fedoraproject.org/rpms/kup
If you want to unretire a
Hi,
Kenneth Goldman wrote:
-Original Message-
From: Clemens Lang
Sent: Tuesday, February 14, 2023 12:59 PM
To: Development discussions related to Fedora
You are right, but fkinit will tell you, so I don’t think we need to
clarify this in
the documentation:
:) cllang@frootmig
e that the prompt is for
only the token)
Enter OTP Token Value:
:) cllang@frootmig:~$
HTH,
Clemens
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email t
Hi,
Alexander Sosedkin wrote:
In RPM world, I've even entertained an idea of having a subpackage for
auditability not unlike how we have debuginfo, since rebuilding a package
reproducibly requires builddep pinning. But if that's avoidable, I’d
rather just not mix artifacts with meta.
Debian
, but
commonly used software is probably already fixed.
HTH,
Clemens
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Co
,
Clemens
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of
Hi,
Kevin Kofler wrote:
Clemens Lang wrote:
Note that we’re discussing moving openssl to a src-git approach, so it
should eventually become much easier to see the relation between upstream
code and our downstream copy.
At that point, you have the patent-encumbered files in your (src-)git
Hi,
Michael J Gruber wrote:
Understanding is helped greatly by communication, though. Legal answers
such as "We can not" do not further this understanding, and "We can not
and we can not tell you why" is not much better, but these are the typical
answer we get, not even with a "sorry, but we c
dards.
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
case of running the test with a separate OpenSSL configuration file that
applies weaker defaults.
HTH,
Clemens
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
on how to avoid it.
[1] https://github.com/lsh123/xmlsec/issues/339
HTH,
Clemens
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F
basically mean “I don’t care about
encryption”. In these cases, why not just use plain HTTP, or other
unencrypted protocols instead?
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
2
when SECLEVEL is 2.
In conclusion: Ubuntu isn’t ahead of us here.
[1]: https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
mail server administrator and asking them
to support modern TLS versions.
HTH,
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
I’ll start working on this
now.
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/
at we are
proposing.
HTH,
Clemens
--
Clemens Lang
RHEL Crypto Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org
58 matches
Mail list logo
