Markaos

@Markaos@lemmy.one
1 Post – 121 Comments
Joined 1 years ago

It's a very short Python script and I'm confident I get the general idea - there's absolutely nothing related to current time in the decryption process. What they refer to as a "time lock" is just encrypting the key in a loop (so the encrypted key from one loop becomes the plain text for the next one) for the specified duration and then telling you how many iterations were done. That number then becomes a second part of the password - to decrypt, you simply provide the password and the number of iterations, nothing else matters.

def generate_proof_of_work_key(initial_key, time_seconds):
    proof_key = initial_key
    end_time = time.time() + time_seconds
    iterations = 0
    while time.time() < end_time:
        proof_key = scrypt(proof_key, salt=b'', N=SCRYPT_N, r=SCRYPT_R, p=SCRYPT_P, key_len=SCRYPT_KEY_LEN)
        iterations += 1
    print(f"Proof-of-work iterations (save this): {iterations}")
    return proof_key


def generate_proof_of_work_key_decrypt(initial_key, iterations):
    proof_key = initial_key
    for _ in range(iterations):
        proof_key = scrypt(proof_key, salt=b'', N=SCRYPT_N, r=SCRYPT_R, p=SCRYPT_P, key_len=SCRYPT_KEY_LEN)
    return proof_key

The first function is used during the encryption process, and the while loop clearly runs until the specified time duration has elapsed. So encryption would take 5 days no matter how fast your computer is, and to decrypt it, you'd have to do the same number of iterations your computer managed to do in that time. So if you do the decryption on the same computer, you should get a similar time, but if you use a different computer that is faster at doing these operations, it will decrypt it faster.

Yeah, even the TLDR makes it sound more like Qualcomm is yielding to the pressure from OEMs who want to be able to offer longer updates

Does UEFI initialize all the cores? I know the OS always starts with only one core available, but I'm not sure if UEFI just disables the cores after it's done its thing, or if it doesn't touch them. Because if it stays on core 0 and never even brings the other ones up, then this issue with core 2 could let it boot this far just fine.

If it is an Arch-based distro (sorry, I don't recognize the package manager), then this might just be the recent Wine update that made it 700 MB smaller (which would mean the rest of your system grew 300 MB)

I made a post here about it: this one

Btw, is there a way to link to a post in a way that resolves on everyone's separate instance instead of hard coding it to my instance?

1 more...

From this point of view is systemd disaster because it is almost everywhere in the system - boot, network, logs, dns, user/home management…

That's almost like complaining that GNU coreutils is a disaster from KISS point of view because it includes too many things in a single project - cat, grep, dd, chown, touch, sync, base64, date, env... Not quite, because coreutils is actually a single package unlike systemd.

The core systemd is big (IMHO it needs to be in order to provide good service management, and service management is a reasonable thing to include in systemd), but everything you listed are optional components. If your distro bundles them into one package, that's on them.

2 more...

I don't think that's a similar situation - the Linux kernel lost some functionality there, but in this case Ext2 filesystems are still fully supported by the Ext4 driver, so there's no difference in "hardware" support.

The separate Ext2 driver was being kept for embedded devices with extreme memory or storage limitations where saving some kilobytes by not having all the new Ext3/4 features was useful, but when you can afford the extra memory, there's no reason not to just use the Ext4 driver for all Ext2/3/4 filesystems.

They would have to sign another contract for another 24 months to get it, nobody was getting an upgrade on the existing contract because it's just a bundle of Google services (One, YT Premium etc.) and financing on the phone. And if you don't care about the services, Google's two year financing is cheaper than this bundle.

3 more...

Generally yes. The Fn key is usually handled either by the keyboard itself or by the BIOS, and the OS just sees the resulting key presses as if the keyboard had all the buttons. Can you not find such a switch in your BIOS? Saying what vendor it is might also help someone help you.

I don't really see the big problem here? Like sure, it's silly that it's cheaper to make wireless headphones than wired ones (I assume - the manufacturers are clearly not too bothered by trademarks and stuff if they put the Lightning logo on it so they wouldn't avoid wired solution just due to licensing fees), but what business does Apple have in cracking down on this? Other than the obvious issues with trademarks, but those would be present even if it were true wired earphones. It's just a knockoff manufacturer.

Cheapest possible wired earphones won't sound much better than the cheapest possible wireless ones, so sound quality probably isn't a factor. And on the plus side, you don't have multiple batteries to worry about, or you could do something funny, like plugging the earphones into a powerbank in your pocket and have a freak "hybrid" earphones with multi-day battery (they're not wireless, but also not tethered to your phone). On the other side, you do waste some power on the wireless link, which is not good for the environment in the long run (the batteries involved will see marginally more wear)

Honestly the biggest issue in my mind is forcing people to turn on Bluetooth, but I don't think this will change anyone's habits - people who don't know what Bluetooth is will definitely just leave it on anyway (it's the default state), and people technical enough to want to turn it off will recognize that there's something fishy about these earphones.

9 more...

I mean, it's called "LaTeX by example", so there's a pretty good chance it's written in LaTeX, which you do indeed compile to get the PDF or whatever output you want.

Also, just having access to the source doesn't make it open source - that requires more freedoms. For example, here's GitLab Enterprise Edition source code, fully functional and ready to be used. And also officially described as the proprietary edition of GitLab by the GitLab company itself. Why? Because its license pretty much boils down to "you can use this only for testing and development, unless you have paid for it".

Convenience (after you install it, all you have to do is enter the code and you're connected, no other setup required), familiarity (it's the default name people will think of or find if they want remote access - that alone means they can get away with pushing their users slightly more) and - IMHO most importantly - connectivity: if two computers can connect to the TeamViewer servers, they will be able to connect to each other.

That's huge in the world of broken Internet where peer to peer networking feels like rocket science - pretty much every consumer device will be sitting behind a NAT, which means "just connecting" is not possible. You can set up port forwarding (either manually or automatically using UPnP, which is its own bag of problems), or you can use IPv6 (which appears to be currently available to roughly 40% users globally; to use it, both sides need to have functional IPv6), or you can try various NAT traversal techniques (which only work with certain kinds of NAT and always require a coordinating server to pull off - this is one of the functions provided by TeamViewer servers). Oh, and if you're behind CGNAT (a kind of NAT used by internet providers; apparently it's moderately common), then neither port forwarding or NAT traversal are possible. So if both sides are behind CGNAT and at least one doesn't have IPv6, establishing a direct link is impossible.

With a relay server (like TeamViewer provides), you don't have to worry about being unable to connect - it will try to get you a direct link, but if that fails, it will just act as a tunnel and pass the data between both devices.

Sure, you can self host all this, but that takes time and effort to do right. And if your ISP happens to use CGNAT, that means renting a VPS because you can't host it at home. With TeamViewer, you're paying for someone else to worry about all that (and pay for the servers that coordinate NAT traversal and relay data, and their internet bandwidth, neither of which is free).

1 more...

So, if I understand this correctly, open source means free beer, just not if you sell the end product.

Yes, once you give the beer to someone, you can't require any further payments no matter what they do with it. Free software philosophy says users are free to use the software however they wish and for whatever purpose they wish without any barriers (like having to pay for commercial use).

its all a scam for free work for corpos then. Very disappointing.

I'm sorry you feel that way, and it's becoming a not-so-rare sentiment lately (or at least I've started noticing it more), but I don't agree. Look at (A)GPL and how many companies are doing their best to avoid such code - like when Google made their own C library for Android and even stated that its main goal was to avoid copyleft licenses. I've also seen plenty of people say that GPL code is pretty much useless for their work due to their company's policies forbidding its use.

I also think that revenue-based loyalties screw over small companies the most - sure, you get the donations from the massive companies that can work with 1% of their revenue gone while also keeping it free for non-commercial users, but in my view you also help those same massive corporations by making the software less viable for their smaller competitors who don't have the economies of scale on their side, and for whom that 1% might legitimately break the bank.

And to be clear, I don't mean any of my arguments as some kind of "gotcha! Look, I'm right and you're wrong", I just thought I might share my reasoning for why I don't think your statement is fair.

The astrophotography mode on Pixels (the only way to get 4 min exposure in the default camera app) works by taking quite a few photos with shorter exposures and then matching them up in post processing.

You even get a short animation at the end where every captured photo gets processed using the rest, so you can see stars moving around during the capture.

3 more...

If a thief knows your PIN (by watching an earlier unlock), Android is now requiring “biometrics for accessing and changing critical Google account and device settings, like changing your PIN, disabling theft protection or accessing Passkeys, from an untrusted location.”

Sounds great for Pixel 6 series with their reportedly highly reliable fingerprint sensors /s

Honestly, I'm not sure what to think about this - extra protection against unauthorized access is good, but requiring biometric verification with no apparent alternative irks me the wrong way.

Maybe that's just because of my experiences with Nokia 5.3 and its awful rear fingerprint sensor with like 10% success rate. But then again, there will eventually be phones with crappy sensors running Android 15.

5 more...

Here's Stallman's/FSF's view on requiring loyalties (lol) royalties (read the whole section, it's explicitly stated at the end), and here's similar requirement in OSI's Open source definition.

You are free to use whatever license you wish, but don't call it FOSS/Open source if you don't agree with their definitions.

2 more...

No, kernel immediately stops execution of all normal processes once it gets into a kernel panic, and there's no way for processes to hook into this functionality. It is intended to be the emergency stop state when the kernel realizes it doesn't know what's going on and it would be dangerous to continue executing. So it does the bare minimum to report the issue and then stops even its own execution.

There's also a softer variant of the kernel panic called kernel oops that should let the user choose to continue if they think the risk of data corruption doesn't outweigh losing all data currently in memory. But just like the kernel panic, it is handled completely inside the kernel and userspace is frozen until the user chooses to continue.

This is intended for situations where systemd runs into an unrecoverable issue while booting (for example you have misconfigured fstab and a required disk is missing). Without this, you just get thrown into the terminal with some error messages that might not make much sense to you if you don't have a decent understanding of Linux. Now, you get a more newbie friendly message and a QR code that should bring you somewhere you can learn more about possible causes and troubleshooting steps.

The idea is to use TPM to store the keys - if you boot into a modified OS, TPM won't give you the same key so automatic unlock will fail. And protection against somebody just booting the original system and copying data off it is provided by the system login screen.

Voilà, automatic drive decryption with fingerprint unlock to log into the OS. That's what Windows does anyway.

7 more...

But "open source" doesn't even mean that you can reproduce it or use it for free.

You're thinking of source-available licenses. Open source has a clear and widely accepted definition that requires a certain level of freedom. You're free to ignore this definition, but you can't expect the rest of the world to do the same.

To be clear, open source allows for only providing access to paying customers, but those paying customers are then free to use and distribute their copies without any further payment. Then it wouldn't be open source anymore.

2 more...

Or is there any functional difference between the two methods?

Can't test right now, but I have a strong suspicion you will have trouble getting IP broadcast to work. Normally broadcast address is calculated by setting all bits after the network prefix to 1, but your computer believes to be in a /32 "network". It won't broadcast over routes that are not part of its network.

And even if you calculate the broadcast address successfully (maybe the software you use has /24 hardcoded for whatever reason), no computer configured with a /32 address will receive it - 192.168.0.255 is not within the 192.168.0.1/32 network, so it will probably get forwarded according to your routes if you have forwarding enabled (except it shouldn't in this case with one network interface, because you never send packets back the way they came from)

4 more...

It is, and it's the reason Pixel 6 and 7 series had so many issues with poor battery life and weak modem. Although it appears that the third generation Tensor CPUs in Pixel 8 have major improvements on both of these pain points.

Still, that probably brings Pixel 8 only to the cheap-ish midrange standard when it comes to cell signal, as the Pixel 7 phones were atrocious and 6s were apparently even worse.

Yup, it's dead. Here's the Internet Archive's snapshot: https://web.archive.org/web/20230626075444/https://manjarno.snorlax.sh/

xrandr is Xorg only, it doesn't work with Wayland. You should be able to make SDDM use your Plasma display configuration - https://wiki.archlinux.org/title/SDDM#Match_Plasma_display_configuration

No clue if that's going to fix your issues, but at least it's supposed to work with Wayland.

No, face unlock on Pixels doesn't do anything to illuminate your face, it simply refuses to work if the lighting's too dim. It's actually worse than the face unlock in Google Smart Lock in dealing with low light environments.

1 more...

It should not be controlled by a company that is known to make you lose your games.

Are you referring to the fact that Valve promotes digital game distribution (which is a very fair view), or are you talking about some incident where Valve removed games from people's libraries? Because if it's the second one, then I would really like to hear about it.

3 more...

Cool, so it's like two years ago

Oh...

Oh no

They seem too small and consistent in size to just be bundles of system apps that got security fixes

Correct, just one note here: system apps (both APK apps and APEX system modules) are updated through Google Play like all other apps, the monthly security patches are a layer below that - it updates the base OS files like firmware and kernel modules. More info about APEX

Are they like differential patches or something?

Yes, that's exactly what they are. Small differential patches (often called delta patches / delta updates) to the files.

Btw apps are also getting delta updates through Google Play for at least a few years now (5-ish?)

And what happens while the 'finishing system update' notification is shown?

Android Runtime (ART) works by compiling the Java bytecode in apps to native code before running them - it's called "ahead of time compilation". This compiled native code is specific to the device, OS and system modules, and some of the modules probably changed during an update - that means the OS has to recompile all the native code against the new updated modules, and that takes some time to do for all installed apps. There can also be updates to the ART module itself that improve the way ART compiles code, and that also requires recompilation to have effect.

as far as I can tell the phone remains unlocked while updating, so why do they need it to be booted to finish the update? Is it just to turn on the phone faster?

There's a mechanism called A/B partitioning where there are actually two copies of the OS installed. To update, you copy the current OS into the other slot, then apply all the updates to it and finally mark it as the active slot. When you boot your phone, the bootloader looks up the active slot and boots it (and switches the primary slot back if it fails to boot a few times in a row).

The OS can be updated during a reboot and that's how some vendors still do it, but the downside is that the phone cannot be used during updating. With A/B partitioning and background updates, you can use your phone like usual and then reboot as quickly as any other reboot to apply the updates.

Yes in the sense that the APIs were made because of flatpak, but not in the sense that devs would need to keep two separate code paths for flatpak vs non-flatpak - portals work everywhere.

4 more...

You still need some privileged process to exploit. Glibc code doesn't get any higher privileges than the rest of the process. From kernel's point of view, it's just a part of the program like any other code.

So if triggering the bug in your own process was enough for privilege escalation, it would also be a critical security vulnerability in the kernel - it can't allow you to execute a magic sequence of instructions in your process and become a root, that completely destroys any semblance of process / user isolation.

If you boot the computer into the currently installed OS, you will be presented with a login screen and will have to enter the correct password to log in (kernel parameters are part of the checksums, so booting into single-user mode won't help you, that counts as a modified OS). If you boot a different OS, you won't get the key off the TPM.

2 more...

I'd love it too with my 7a, but there's no way Google does something nice just 'cause. They've already sold the phones with a shorter support window and they gain nothing by releasing more updates for those devices.

If it's a Flatpak, then installing anything with APT shouldn't help you at all - it is possible to build a Flatpak that accesses host libraries, but it would defeat the point of using Flatpak in the first place. So your xapp issues are moot anyway.

As to the meaning of the output of apt policy: it says that the most up to date libxapp1 is from Linux Mint repos, and that there's also an older version in Ubuntu repos. That means that Linux Mint doesn't provide a xapp package at all, and the only one you could install is the old one from Ubuntu (which conflicts with the newer libxapp1 from LM)

4 more...

Yeah, but a lot of those things will trip the TPM module, so you will get a different decryption key if you for example try to use the single kernel parameter to boot into a root shell. And different decryption key means no access to the data.

See? Hidden in an image, clearly that's steganography! /s

Infinity did pretty much the same thing a few weeks ago. Now I'm a happy Eternity (previously Infinity for Lemmy) user.

That just uses normal fast charging to get to 80%, then stops the charge and finally resumes charging about an hour or two before the planned "charged by" time. No slowing down.

Oh, and it also has (or had on Android 13) a cool bug where it just stops charging if it fails to reach 80% by the time it wants to resume charging (for example if you put the phone on a slow charger late at night - that's how I woke up with 60% battery after 4 hour sleep).

So I just gave up on the idea of using a slow charger to better preserve the battery because the phone clearly wasn't expected to be used that way.

The thing is that they've clearly promised 7 years now, walking back on the promise would cause them massive issues with consumer protection agencies everywhere they sell - they might be toothless in the US, but Google also sells Pixels in Japan and the EU.

Also, the Arch repos are pretty much just an "AUR with binaries" - they contain the same PKGBUILD files used by AUR packages, because that's how Arch packages are built. So you can just download an Arch package PKGBUILD, modify it however you wish, and then build and install it.

I kinda doubt there's going to be any outside contributions to this project, so any non-exclusive license would allow MS to rerelease this under a proprietary license - even the GPL. They own the copyright, so they can release it under as many licenses as they wish.

With software there's way lower barrier to entry and way higher chance of having the patches accepted. With art... Good luck convincing MS that your version of the emoji is worth the hassle of losing the ability to just change the license at any moment.

That requires just unlocked bootloader, not root. In the distant past before full disk encryption you could often use root to replace the bootloader with a new one that doesn't verify what OS it's booting (so you could say that rooting was part of the process of changing ROM), but nowadays it's very rare to be able to do that.

Now you either get a tool from your OEM to unlock your bootloader (and then you can flash ROMs to your heart's desire), or you're screwed.