julian-klode

10 ms·

1.
The pandemic of incomplete OpenSSL error handling(blog.jak-linux.org)
5 points by julian-klode 3mo ago|0 comments
2.
by julian-klode 11mo ago
> though I hope existing well tested rust libraries are used rather than NIHing them and introducing new bugs I think that's much more likely to introduce bugs. Think of it that way, a lot of the Rust libraries are rewriting existin
3.
by julian-klode 11mo ago
Like the last one was/is the inability to comprehend safety of large buffers on ppc64el because the stack clash protector code generated by gcc isn't understood. The one before that was more problems of that sort on armhf where it
4.
by julian-klode 11mo ago
As far as I understand, Fil-C changes the ABI of the system, therefore it requires a new architecture in Debian terminology, e.g. amd64fil. And then you'd need to use multi-arch to pull in amd64fil binaries where that works. We'll
5.
by julian-klode 11mo ago
It's certainly what we aim for in APT. We do have an overwrite of course, since we need to copy uninitiated data around: The cache file is allocated as a whole and written at the end, but not all parts of it are used, but it triggers s
6.
by julian-klode 11mo ago
It's not like I'm in a hurry to switch to Rust and will spend full steam on it. It's amongst the lowest priority items. A lot of the Rust rewrites suffer a crucial issue: they want a different license than what they are rewri
7.
by julian-klode 11mo ago
/me hides in shame
8.
by julian-klode 11mo ago
It's insanely complex, particularly you want _verified_ crypto. Last year (or two years ago?) I had to fix a tiny typo in OpenSSL's ARM assembly for example, it was breaking APT and Postgres left and right, but only got triggered
9.
by julian-klode 11mo ago
> > since it only supports amd64 at this time and is maintained by a single genius. > That's easily fixable. as easily as fixing Rust to work on the remaining 4 architectures? > > It also doesn't help you to attract
10.
by julian-klode 11mo ago
Do keep in mind that a lot of the people involved in these sorts of things are neurodiverse in some ways, and may have significant trouble dealing with change. As teh64 helpfully pointed out in https://news.ycombinator.com/i
11.
by julian-klode 11mo ago
Isn't it also funny that all of these things are done by the same person? In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather th
12.
by julian-klode 11mo ago
Alpha and PA Risc where the predecessors of Itanium fwiw if you want to feel old in an easy to understand way.
13.
by julian-klode 11mo ago
Keep in mind APT is using the GNU dialect of C++, particularly C++ 17, shortly C++ 23. And it always exploits the latest C++ features while at the same time still having workarounds in the code for a lack of namespaces in C++ compilers prio
14.
by julian-klode 11mo ago
We have replaced GnuPG by Sequoia in the previous Debian release.
15.
by julian-klode 11mo ago
Actual cryptography code, the best path is formally verified implementations of the crypto algorithms; with parsers for wrapper formats like OpenPGP or PKCS#7 implemented in a memory safe language. You don't want the core cryptography
16.
by julian-klode 11mo ago
There is no Perl code in APT itself, nor in dpkg on the installing side; Perl is used by dpkg-dev, i.e. when building packages.
17.
by julian-klode 11mo ago
If anyone sees that horrible mess of hacks around pre-STL C++'s lacks of namespace in combination with latest C++ features as part of the C++ community I'd be very surprised :D If APT were a hardcore C++ project surely we'd h
18.
by julian-klode 11mo ago
I wish, but I get new security bugs in those components like every year or so, not all are tracked with security updates to be fair, some we say it's your own fault if you use the library to parse untrusted code. After all the library
19.
by julian-klode 11mo ago
I mean they can't in the first place, because ports only have unstable available
20.
by julian-klode 11mo ago
Fil-C is amazing but is much more problematic than Rust at this point since it only supports amd64 at this time and is maintained by a single genius. It also doesn't help you to attract new contributors. With the changes we made over
21.
by julian-klode 11mo ago
It's rather that GnuPG is ill-regarded for its code immaturity tbh. You don't even need to read the code base, just try to use it in a script: It exits 0 when the verification failed, it exits 1 when it passed, and you have to ign
22.
by julian-klode 11mo ago
Let me assure you it was my own decision. The final paragraph is my paraphrasing of a fellow Debian developer and CTTE member's stated opinion.
23.
by julian-klode 11mo ago
Ports are not part of Debian and particularly don't release with Debian, they only ship unstable.
24.
by julian-klode 11mo ago
Yes that's true and there's synergies but keep in mind I also have a personal mind
25.
by julian-klode 11mo ago
We're really talking about alpha, hppa, m68k and sh4
26.
by julian-klode 11mo ago
Yes sure apt (3.1.7) unstable; urgency=medium . [ Julian Andres Klode ] * test-history: Adjust for as-installed testing . [ Simon Johnsson ] * Add history undo, redo, and rollback features
27.
by julian-klode 2y ago
This is a very contentious topic, you can see my initial take on this in https://blog.jak-linux.org/2023/10/10/a-case-for-different-u... The problem is that's not really true. i.e. consider you get postf
28.
by julian-klode 2y ago
apt-mark showmanual shows you all manually installed packages and apt-mark auto marks stuff as automatically installed. The list of manually installed packages is effectively the "world". The new solver takes inspiration from apk
29.
by julian-klode 3y ago
So hibernate is somewhat unreliable and prone to data loss, image you hibernate after having installed a new kernel, so the decision was made to disable it due to that IIRC, independent of secure boot. With secure boot and lockdown, hiberna
30.
by julian-klode 4y ago
They even should all be supporting efifb?

More ›