Hacker Newsnew | past | comments | ask | show | jobs | submit | kayson's commentslogin

> our recent analysis found over 90 times more malware from sideloaded sources than on Google Play

So what's the solution then? At the same time, I'm curious how this ends up happening to end users. Enabling unknown sources is trivial in a way (it's just one check box and if you try to install an APK from, say, Firefox, it'll take you right there), but how are people even getting to that point??


Phone scammers guiding users to install apps.

Are we really saving that much by not having semicolons? IDEs could probably autocomplete this with high success, and it removes ambiguity from weird edge cases. On the other hand, I've not once had to think about where go is putting semicolons...

I was much more opposed to this early on than I am now. With modern IDEs and extensions handling tabs vs spaces, tab width, and formatting, python ends up being very easy to read and write. I use it daily, and while I hate it for other reasons, I can't remember the last time I had any issues with indentation.

I must disagree but only a tiny bit. modern IDEs try to indent and attempt to add indentation as you code which can cause problems sometimes.

tabs vs spaces is very painful still when copying code that is in a different format. it's not just tabs and spaces, but the width of the tabs and the spaces. Even with VSCode extensions and sublime text extensions I've struggled a lot recently with this.

I commented on a sibling thread just now, but it is still very easy in python to mess up one level of indentation. When I caught bugs of that sort, it was introduced either when copy pasting, when trying to make a linter happy and doing cosmetic cleanup, or when moving code around levels of indentation, like introducing a try/except. I had one recently where if I recall correctly I moved a continue statement under or out of a try/except when messing around with the try/except logic. it was perfectly valid, and didn't stand out much visually, pydnatic and other checkers didn't catch it either. It could have happened with a '}' but it's easier to mess up a level of indentation than it is to put the '}' at the wrong level. a cosmetic fix results in a logic bug because of indentations in python. with curly's, a misplacement of that sort can't happen because of indentation or cosmetic/readability fixes.

what the curly approach asserts is a separation of readability and logic syntax.

The interpreter/compiler should understand your code first and foremost, indenting code should be done, and should be enforced, but automatically by the compiler/interpreter. Python could have used curly braces and semi-colons, and force-indented your code every time it ran it to make it more readable for humans.


I really wanted to use vscodium but had to go back to vscode proper because the remote ssh extension is just nowhere near as good. The open source one uses a JS library to implement the SSH protocol rather than using a system binary which means many features (GSSAPI) aren't supported. Also just seems like a bad idea to use an SSH implementation that's not nearly as battle tested as openssh...

Odd to me that the focus seems to be on the inactivity of Google's package when https://github.com/gofrs/uuid not only conforms to the newer standard but is actively maintained.


I get a kick out of publishing libs with no external deps. Regardless of reasoning, this change makes that easier.


especially when they don't depend on libc.


While the uuid package is actively maintained, it hasn't had a release since 2024. Indeed, there's an open issue from June 2025 asking about it: https://github.com/google/uuid/issues/194


The RFC isn’t changing, is it?


I’m not sure of the state of that particular library, but yes, the RFC has changed significantly. For instance, the UUIDv7 format changed from the earlier draft RFC resulting in incompatibilities.

This is an example of an unmaintained UUID library in a similar situation that is currently causing incompatibilities because they implemented the draft spec. and didn’t update when the RFC changed:

https://github.com/stevesimmons/uuid7/issues/1

Any Python developer using the uuid7 library is getting something that is incompatible with the UUIDv7 specification and other UUIDv7 implementations as a result. Developers who use the stdlib uuid package in Python 3.14+ and uuid7 as a fallback in older versions are getting different, incompatible behaviour depending upon which version of Python they are running.

This can manifest itself as a developer using UUIDv7 for its time-ordered property, deploying with Python <=3.13, upgrading to Python 3.14+ and discovering that all their data created with Python 3.13 sorts incorrectly when mixed with data created with Python 3.14+.

A UUID library that is not receiving updates is quite possibly badly broken and definitely warrants suspicion and closer inspection.


Alternative take: don't put draft RFCs into prod


It hasn’t been a draft RFC for a couple of years:

https://datatracker.ietf.org/doc/rfc9562/

The problem is not that it is a draft RFC, the problem is that the library is unmaintained with an unresponsive developer who is squatting the uuid7 package name. It’s the top hit for Python developers who want to use UUIDv7 for Python 3.13 and below.


The problem here is a lack of namespaces. A problem the cargo bozos decided to duplicate


Your point is completely invalidated by useless name calling. The people behind cargo are clearly accomplished and serious individuals, and even if you disagree with some of the choices, calling them bozos makes your whole argument unconvincing.


RFC changes aside, the go community has been bit by unmaintained UUID libraries with security issues. Consider https://github.com/satori/go.uuid/issues/123 as a popular example.

The open issue in Google's repo about the package being malicious is not a good look. The community concluded it's a false positive. If the repo was maintained they'd confirm this and close the issue.

Maintaince is much more than RFC compliance, although the project hasn't met that bar either.


There have been committed 3 new features and a seemingly significant bug fix since the last release: https://github.com/google/uuid/compare/v1.6.0...HEAD

If the library just existed as a correct implementation of the RFC without bugs or significant missing features, that would be one thing. But leaving features and bug fixes already committed to the repository unreleased for years because the maintainer hasn't cut a new release since 2024 is a bad sign.


The proposal is 3 years old


There was a similar (in spirit) project to upscale and resample Avatar the Last Airbender [1] because the original DVD release was so awful. Shortly after, Nickolodeon released a blu-ray boxed set that was quite a bit better than the DVDs, but it still had some issues. Doesn't seem anyone has decided to upscale it again [2].

1: https://www.reddit.com/r/TheLastAirbender/comments/5hv4en/no...

2: https://github.com/brucethemoose/AvatarUpscale


Is MAC whitelisting anything but security theater? Isn't it trivial to determine a valid client MAC then spoof it?


What makes you say that? It does not seem trivial at all to guess a valid MAC.


It's not just a guess.

Any decent sniffer (e.g. airsnort) can immediately identify all associations between all WiFi/Bluetooth devices. DD-WRT (router firmware/OS) has this WiFi-associations detector built-in ("local WiFi map"). There is no need to attempt any sort of hack — associations are publicly-broadcast information.

Then, just pick any authorized MAC and duplicate as your own.


The MAC addresses of all the Wi-Fi clients are broadcasted in plain radio format all over the 2.4GHz. It is trivial.


It's in managmenet frames that you can sniff.


Does wpa3 pmf fix this particular issue?


This isn't considered "broken" — it's part of how WiFi works/associates.


I am really really weary of installing anything from "user" repos, whether it's AUR or Fedora copr. It feels like the wild west. Admittedly, maintainers of Debian packages could just as easily mess up or release something malicious, but I at least get the impression that the bar is higher...


That's a good instinct and default. But if you do the process consciously, like OP advices, AUR can be more secure and predictable than alternatives as you build locally from first-party sources.

(Same can't be said for COPR or PPAs)


> sudo echo $NUM_PAGES > /proc/sys/vm/nr_hugepages

This won't work :) echo will run as root but the redirection is still running as the unprivileged user. Needs to be run from a privileged shell or by doing something like sudo sh -c "echo $NUM_PAGES > /proc/sys/vm/nr_hugepages"

The point gets across, though, technicality notwithstanding.


Or

    echo $NUM_PAGES | sudo tee /proc/sys/vm/nr_hugepages 

I've always found it odd that there isn't a standard command to write stdin to a file that doesn't also write it to stdout. Or that tee doesn't have an option to supress writing to stdout.


You forgot the "sudo" before "tee"

> write stdin to a file that doesn't also write it to stdout

You mean like "dd of=/path/file" ?


I physically/literally squinted when I saw disk destroyer.

I know it's useful for other things, but it has become a fearful instinct at this point.


If my memories serves me right it was meant to be "Copy Convert" but "cc" was already taken for "C Compiler" so they went to the next letter in the alphabet (alpha beta), hence "dd". Thanks for listening to my TED talk of useless and probably false information :)

edit: i will be stealing disk destroyer, though


    According to Dennis Ritchie, the name is an allusion to the DD statement found in IBM's Job Control Language (JCL), where DD is short for data definition  https://en.wikipedia.org/wiki/Dd_%28Unix%29#History


I've always thought that there should be `cat -o output-file` flag for that. GNU coreutils have miriads of useless flags and missing one actually useful flag LoL.

And probably `echo -o output-file` as well.


> I've always found it odd that there isn't a standard command to write stdin to a file that doesn't also write it to stdout

If you happen to have moreutils installed, you can do that with pee

    echo $NUM_PAGES | sudo pee 'cat > /proc/sys/vm/nr_hugepages'


why not write sh -c then?


Because 'sh' isn't in moreutils and is harder to remember, next question.

Why use something portable when you can use cat pee?


Personally? Because I hate the smell.


It’s not an option or feature because it’s built into the shell. Just slap a > /dev/null on the end.


That works, but it feels wasteful to needlessly copy it, and it is verbose.


Great point, I was running as root so I didn't pick this up. Corrected, thank you!


Are there any pandas alternatives that offer stronger column typing? Ideally something where I can have the schema defined in advance, validate the data, then have the type checker be smart enough to know that df.foo exists and is float and df.bar doesn't.

I tried pandera and it left a lot to be desired. Static frame [1] seems promising but doesn't appear to be popular for some reason.

1. https://static-frame.readthedocs.io/en/latest/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: