• 0 Posts
  • 157 Comments
Joined 3 years ago
cake
Cake day: June 10th, 2023

help-circle

  • I don’t get how that output showcases anything, unless he had run that against a known instance of forgejo so the owners of that instance could confirm that he actually executed code. But he’s only showing a text file, that’s like saying look I hacked super_secure_self_hosted_service:

    python hack_it.py localhost:3000
    
    Hacked!
    

    For all we know chain_alpha.py is just a bunch of prints.

    Also, even if it is real (which I don’t really doubt, but I have seen no proof) holding the information instead of properly disclosing it is just childish. It’s not a carrot methodology, it’s a stick one, and one without a carrot. This is the sort of thing you do to big companies with no morals, doing it to a small open source project is just wrong, they don’t have the manpower or money to redo the investigation you already did. Release a CVE, talk to the devs, and/or push a PR, but saying “I found a vulnerability but I won’t tell you about it” is just dumb.


  • That article has lots of issues:

    17% of the most popular Rust packages contain code that virtually nobody knows what it does

    That’s not true at all, the article where he got that information from says:

    Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.

    So, of the 999 most popular crates analyzed 0% contains code nobody knows what it does.

    He then lists some ways packages can be maliciously compromised:

    1. Steal credentials and impersonate a dev
    2. Misleading package names
    3. Malicious macros (this one is interesting, had never considered it before)
    4. Malicious build script

    And his solutions are:

    1. Bigger std library (solves none of the above)
    2. Source dependencies (solves none of the issues he showed, only the issue that happens in 0% of packages where binary doesn’t match the source and is detectable)
    3. Decentralized packages (which worsens every security concern)
    4. Centralized Checksum database (so a centralized package manager is bad, but a centralized Checksum index is good? How does that work?)

    Honestly I can’t take that article seriously, it grossly misinterpreted another study, presents problems that exist on every single package manager ever, doesn’t propose ANY valid solution, and the only thing he points to as a solution suffers from ALL of the same issues and then some.




  • Hey, I’ve been using silverbullet for a year or so. The first thing that I will say is that if you don’t care for client/server I would suggest just keep markdown files in a folder, that’s very portable and there are tons of plugins for editors to track that, that’s what I was doing before Silverbullet, and way before that it was org-mode which I still miss a few features sometimes. I’ve never used LogSeq, for any extended period so can’t talk about specifics there.

    From my experience these are the things I like about Silverbullet:

    • It’s mostly markdown, this means that if I ever have an issue with SB I can just access the files directly
    • Client/Server means I can add quick things from my phone/tablet/different computer very easily
    • Sync mode means I can edit even when offline and have it sync later
    • It is extremely hackable, if you can program you can make it do what you want and it can be amazing at times

    And these are some things I dislike about it:

    • Syntax doesn’t seem to be stable. I have some old files that don’t draw tables anymore because something changed in the extra syntax they have for queries.
    • It is very bare-bones, it doesn’t have the bells and whistles of other larger products and it never will, it’s not what it’s about.

    At the end of the day I think it’s a great tool for what it does, but you should understand what it is. If you’re expecting charts, diagrams or similar you will be sorely disappointed. If you expect a solid note taking app I think you’ll be very happy with it.


  • I theoretically have Diun setup, but realistically I just run my Ansible playbook weekly and have most containers set to latest. The exceptions being things that sometimes need special steps when upgrading such as Immich or critical stuff I want special attention such as Athelia/Authentik, for those I subscribe to their releases via RSS so I can update them easily, which usually is just changing a value in my Ansible configuration, but if extra changes are needed I can adapt them.




  • I shutdown my Desktop daily, sometimes more if for example I’m playing in the morning and going out for lunch and coming back in the evening and playing again. In short if I’m going to spend over an hour not using it I’ll power it off, no reason to keep it on and honestly it powers on almost as fast as coming back from hibernation so why bother? That made sense before SSDs, but nowadays I don’t see much reason.

    There’s one big exception, and that is sleeping in the middle of a game, to be able to be back in the game in seconds. It’s one of my favorite features of the Steam Deck, but I haven’t tried it on my desktop because I usually use it for other stuff too so it’s not as useful there.


  • But what is a trusted provider? How can you trust it? How sure are you that you’re not being MitM? Have you fully manually verified that there’s no funky flags in curl like -k, that the url is using SSL, that it’s a correct url and not pointing at something malicious, etc, etc, etc. There are a lot of manual steps you must verify using this approach, whereas using a package manager all of them get checked automatically, plus some extra checks like hundreds of people validating the content is secure.

    To do apt get from an unknown repo, you first need to convince the person to execute root commands they don’t understand on their machine to add that unknown repo, if you can convice someone to run an unsafe command with root credentials then the machine is already compromised.

    I get your point, random internet scripts are dangerous but random internet packages can also dangerous. But that’s a false equivalence because there are lots of safeguards to the packages in the usual way people install them, but less than 0 safeguards to the curl|bash. In a similar manner, if this was a post talking about the dangers of fireworks and how you can blow yourself up using them your answer is “but someone can plant a bomb in the mall I go to, or steal the codes for a nuclear missile and blow me up anyways”.


  • But those are two very different things, I can very easily give you a one liner using curl|bash that will compromise your system, to get the same level of compromise through a proper authenticated channel such as apt/pacman/etc you would need to compromise either their private keys and attack before they notice and change them or stick malicious code in an official package, either of those is orders of magnitude more difficult than writing a simple bash script.








  • Warning, I’ve had an issue in the past where I couldn’t play a game (Deus Ex Mankind divided) because it needed a specific instruction set on the CPU (SSSE3). While not your specific case since the FX-8350 supports SSSE3 (I should know, that was the exact CPU I switched to to be able to play the game) there might be newer instructions sets that this old CPU does not support.

    Also that GPU is older than what people like to remember, from a time where AMD was the worst GPU option on Linux. It’s very likely that the open source driver is good enough for that card by now, but there’s a good chance you might need to wrestle with the AMD proprietary GPU driver (fglrx) which is worse than the Nvidia one in some aspects and some distros don’t even package it anymore.

    If you plug your Nvidia GPU that rig would be usable for gaming, I’m not sure what fps you would get as games keep getting updates and old hardware remains the same so old benchmarks might not be reliable, but I suppose it should run plenty of stuff.


  • You used Linux like Windows and got bad results, OP treated Windows like Linux and got bad results. The problem is neither OS but how familiar you are with it and their peculiarities.

    That being said, GPU drivers are not a rough edge on Linux, only Nvidia drivers are. And even then it’s usually a single click/command to install the proprietary drivers if you need them, otherwise the open source ones work like a charm. This used to be more of a problem a few years back, when both manufacturers used proprietary drivers, but AMD ones are open now and therefore integrated into the mainstream kernel, so they just work.