| 10 Oct 2025 |
 leona | * found a not maintained TLS impl version (mbedtls_2), marked as vulnerable for now: https://github.com/NixOS/nixpkgs/pull/450688 | 14:26:09 |
 niklaskorz | https://github.com/NixOS/nixpkgs/pull/450729 | 16:48:13 |
| 11 Oct 2025 |
|  midischwarz12 joined the room. | 21:01:41 |
| 12 Oct 2025 |
| midischwarz12 removed their profile picture. | 02:45:02 |
| midischwarz12 set a profile picture. | 02:45:11 |
|  Anton (he/him) changed their display name from Anton to Anton (he/him). | 13:18:01 |
| 13 Oct 2025 |
| niklaskorz | nvidia 535 update with beforementioned CVE fixes:
https://github.com/NixOS/nixpkgs/pull/451618 | 09:43:33 |
 hexa | https://seclists.org/oss-sec/2025/q4/26 | 21:54:56 |
| hexa | * https://seclists.org/oss-sec/2025/q4/26 boringssl | 21:55:02 |
| hexa | https://seclists.org/oss-sec/2025/q4/27 poppler | 21:55:17 |
| hexa | requires poppler-25.10.0 | 22:27:01 |
| hexa | * requires poppler-25.10.0 (Jan Tojnar) | 22:27:09 |
| hexa | https://gitlab.freedesktop.org/poppler/poppler/-/commit/4ce27cc826bf90cc8dbbd8a8c87bd913cccd7ec0 | 22:27:29 |
| hexa | https://webkitgtk.org/security/WSA-2025-0007.html webkitgtk | 23:11:01 |
| 14 Oct 2025 |
 vcunat | The boringssl thread doesn't seem very convincing, i.e. no claim is made that the leak goes beyond key length and similar "uninteresting" parameters. | 08:56:06 |
| vcunat | All crypto libs will take longer time when using longer keys, I believe. (up to some exceptions maybe when the difference in length is small) | 08:57:39 |
 Jassuko | Being able to reduce the search space to a specific amount of bits for the private key is a way more information than you might expect. EC priv key is practically a number between 1 and N-1, where N is the order of the curve. For example with P-256 curve you can have a private key that has 253 effective bits in its representation. Knowing this would directly allow you to limit your search space for figuring out the private key to under 1/8 of the full key space.
The practical implications as of now probably don't warrant any direct panic or actions, but building cryptography things is generally based on a strict set of design goals and delivering 100% of the promises given, so in that sense this is a timing side channel which can reveal few bits worth of information of the private key whenever an oracle exists that allows the repeated timing measurements. Well worth fixing and updating, even though there would not be need for a panic-mode actions at this point.
Besides, all kinds of weakenings left unpatched tend to gather up, and then the day comes when your security gets broken because someone figured a way to use those things together in clever ways. | 14:57:17 |
| vcunat | I don't think that's what the post implied. | 14:59:02 |
| vcunat | (but it was short) | 14:59:13 |
| vcunat | * (but it was short and didn't go into details) | 14:59:20 |
| vcunat | Reducing search space to 1/8th is unpleasant but not a security risk. | 14:59:56 |
| vcunat | * Either way, reducing search space to 1/8th is unpleasant but not a security risk. | 15:00:03 |
| vcunat | I can buy 8-times more powerful computer easily. | 15:00:23 |
| Jassuko | The test vectors in the git was a bunch of private keys that has different amounts of effective bits in them. I'd say this is probably the relevant context of the thing. | 15:00:39 |
| vcunat | Let's move this to #security-discuss:nixos.org though. | 15:00:52 |
|  Phil Hale joined the room. | 16:26:17 |
 Jan Tojnar | https://github.com/NixOS/nixpkgs/pull/451215 | 16:34:18 |
|  pinpox changed their display name from pinpox to reaktor. | 21:14:03 |
| pinpox changed their display name from reaktor to pinpox. | 21:14:04 |
| Jan Tojnar | https://github.com/NixOS/nixpkgs/pull/452081
| 21:56:15 |
