• 0 Posts
  • 81 Comments
Joined 10 months ago
cake
Cake day: March 12th, 2025

help-circle






  • I meant the following:

    1. Find out the Debian package is too old
    2. Create Arch Live USB
    3. Boot Arch Live USB
    4. Copy GRUB config from the Debian install to the current Arch live system
    5. Install the up-to-date GRUB while in the Arch environment

    The bootloader installer package is distro dependent, the bootloader the package installs isn’t. You can boot Debian no matter if the GRUB is installed from Debian stable, Debian Sid, Arch, Fedora or even FreeBSD. Otherwise, dual booting wouldn’t work.

    Like I said, I’ve done that before, though with SystemD Boot instead of GRUB, which was a bit simpler due to how the bootloader is configured.



  • As it’s a bootloader, it should make almost no difference which distribution was used to install it. (I’m not sure if Debian patches their GRUB.) I just used Arch as an example, as it is famous for being up to date. And, no matter where it’s installed from, if you’ve made changes to GRUB’s configuration, you’ll have to copy it over to the live distribution to keep your changes.

    Yes, Debian Sid might be more familiar for Debian users, but that’s it.

    Edit: You said “get the grub debs from Debian sid”, but installing Sid packages on non-Sid systems isn’t something that you should do.




  • Lemmy is not GPLv2, but AGPLv3.

    So, the game would have to be (A)GPLv3. (The licenses are fairly interoperable. IIRC you can use AGPL components in GPL software if you abide by the terms of the AGPL.)

    Viral licenses are nice and all, but they’re not without their drawbacks. I caught GPL recently (the slightly rarer Affero v3 strain) and now no DNA testing companies want me as a customer. I can no longer write MIT or BSD licensed code. Whenever I open a project, a LICENSE file appears within ~15 minutes of contact. I hope to recover soon.






  • After a quick look, looks like it tries to split the (unencrypted) hostname into multiple packets, or at least scramble it slightly. I’m not sure how much it helps in practice, but it might help against naïve filtering/scanning, as the hostname is either sent in different packets, or split and sent unordered in the same packet. It probably only helps if encrypted client hello isn’t supported.

    TL;DR: If I’ve understood everything correctly, it just moves chunks of the plaintext hostname around & tries to split it into multiple packets.

    Note: Mostly based on comments, as it’s late & I’m too tired to parse too much cryptography code.

    Full source of the limit_chunks function, formatted with Rustfmt:

    const fn limit_chunks<'a>(
        left: (u64, &'a [u8]),
        right: (u64, &'a [u8]),
        limit: usize,
    ) -> ((u64, &'a [u8]), (u64, &'a [u8])) {
        let (left_offset, mut left) = left;
        let (mut right_offset, mut right) = right;
        if left.len() + right.len() <= limit {
            // Nothing to do. Both chunks will fit into one packet, meaning the SNI isn't spread
            // over multiple packets. But at least it's in two unordered CRYPTO frames.
        } else if left.len() <= limit {
            // `left` is short enough to fit into this packet. So send from the *end*
            // of `right`, so that the second half of the SNI is in another packet.
            let right_len = right.len() + left.len() - limit;
            right_offset += right_len as u64;
            (_, right) = right.split_at(right_len);
        } else if right.len() <= limit {
            // `right` is short enough to fit into this packet. So only send a part of `left`.
            // The SNI begins at the end of `left`, so send the beginnig of it in this packet.
            (left, _) = left.split_at(limit - right.len());
        } else {
            // Both chunks are too long to fit into one packet. Just send a part of each.
            (left, _) = left.split_at(limit / 2);
            (right, _) = right.split_at(limit / 2);
        }
        ((left_offset, left), (right_offset, right))
    }
    

    Same, but for write_chunk:

    fn write_chunk<B: Buffer>(
        offset: u64,
        data: &[u8],
        builder: &mut packet::Builder<B>,
    ) -> Option<(u64, usize)> {
        let mut header_len = 1 + Encoder::varint_len(offset) + 1;
    
        // Don't bother if there isn't room for the header and some data.
        if builder.remaining() < header_len + 1 {
            return None;
        }
        // Calculate length of data based on the minimum of:
        // - available data
        // - remaining space, less the header, which counts only one byte for the length at
        //   first to avoid underestimating length
        let length = min(data.len(), builder.remaining() - header_len);
        header_len += Encoder::varint_len(u64::try_from(length).expect("usize fits in u64")) - 1;
        let length = min(data.len(), builder.remaining() - header_len);
    
        builder.encode_varint(FrameType::Crypto);
        builder.encode_varint(offset);
        builder.encode_vvec(&data[..length]);
        Some((offset, length))
    }
    

    Link to the MIT license file




  • It’s way more common than you may realize. Intel & AMD (and other x86 CPU manufacturers of the time) did it before the first Crusoe CPU launched. (2000 according to Wikipedia)

    CISC architectures are now seen as inefficient, so all the new ones are RISC and new CISC CPUs just translate the instructions to their intenal RISCier microarchitecture. The CPU’s microcode specifies what an instruction translates to.