• 2 Posts
  • 62 Comments
Joined 8 months ago
cake
Cake day: January 25th, 2024

help-circle
  • One thing I can think of is an overzealous corporate security solution blocking or holding back your email purely for having an attachment, or because it misunderstands/presumes the cipher-looking text file to be an attempt to bypass filtering.

    Other than that might be curious questions from curious receivers of the key/file they may not understand, and will not be expecting. (“What’s this for? Is this part of the contract documents? Oh well, I’ll forward it to the client anyway”)

    Other than that it’s a public key, go for it. Hard (for me anyway) to decide to post them to public keychains when the bot-nets read them for spam, so this might be the next best thing?



  • The way I understand it, I think the real issue here is that Proton Drive should clear the sync state or identity when uninstalled. The identification of the PC should be unique to each install, so that when you reinstall it later it understands that it is now a “new” system needing to be reworked from scratch, and that the empty folder is awaiting initial download, not mass cloud deletion. Would that lead to multiple copies in the “Computers” backup section? Sure, but that can be a good thing too, or at least better than wiping the drive, and more easily remedied.






  • Since you mention setup instead of any manual install screwery, I’d say root(uid 0) is still very real, you just didn’t setup any login for it. Every time you sudo (substitute-user-do), you(probably uid 1000) are running that command as root instead of you. In fact, just sudo -i and you are now “logged in” as root.

    Edit: Missed the context. Should still be useful info but you probably are not accidentally remoting into an account you never setup the login for.


  • Raspbian is sometimes a compromise between security and usability, because it is designed to go into the hands of new users. It also used to ship with a default “pi/rasberry” login hardcoded and IIRC permitted root password login over ssh. Things experience users change or turn off, but needs to start friendly for the rest, you know?

    By doing this, they can take a step in the right direction by separating the root and login user, without becoming annoying asking for a password frequently as a newbie copies and pastes tutorial commands all week.

    And as I said it’s unlikely, even very unlikely, but just not impossible. Everything comes with a risk, I just believe it’s up to you, not me, what risks mean in your environment. Might be you’d like to have the convenience on the home dev server, but rather have as much security as possible on a public facing one.

    Or maybe you’d like to get really dialed in and only allow specific commands to be run without a password, so you can be quick and convenient about rebooting but lock down the rest. Up to you, really, that’s the power of Linux.


  • If you’ve got a VPS at your disposal, many of the homepage softwares I’ve tried over the years have some amount of caching to make them quite fast or even operate offline(“Homer” for one required me to deeply purge my cache as it would still appear when my site was offline…despite having replaced it long ago! 😂). Or, if you wanted to roll your own static HTML page, you can absolutely add a Service Worker for your own offline caching.

    That’s where I’m at now. I use a ServerWorker static HTML for my homepage and tab page on all my devices. This page is a bouncer, checks if I’m at home or not(or if my local dashboard is offline) and either redirects me to the local homepage which has all my HomeLab services on it, or if it fails just tells me I might be abroad or offline and lists a few public websites.

    And yes, this works offline or over a shitty connection. Essentially the service worker quickly provides the cached page from the browser storage, then tries to take the time to check the live version. If it gets one, it updates the cache, if not, enjoy the offline version.



  • In Debian, you will want to modify your /etc/sudoers file to have the NOPASSWD directive.

    So where you find something like this in that file:

    %sudo ALL=(ALL:ALL) ALL

    Make it like this:

    %sudo ALL=(ALL:ALL) NOPASSWD:ALL

    In this example, powers are given to the sudo %group, yours might just say pi or something else the user fits into.

    Also, please note that while this is convenient, it does mean anyone with access to your shell has a quick escalation to root privileges. Some program you run has a shell escape vulnerability and gets a shell without a password, this means they also get root without one too. Unlikely to happen, sure, but I believe one should make informed decisions.







  • Yeah, I can see more of this happening as demand for quality products increases.

    Things that don’t need replaced don’t bring in more money year over year, which means they have to keep coming up with other excuses for you to buy a new one just to stay above water.

    Any time purchases reach critical mass and mostly everyone has bought the “last gizmo you’ll ever need”, they’ll have to release the last-last gizmo you’ll ever need.

    One-time purchase forever mouse would just mean once sales drop they need to release the forever-ever mouse, now with an extra button, then when that one peaks, the forever-and-ever mouse, with one more button than that.

    Or they’ll hit a ceiling and go the way of Instant Pot.

    It feels like a choice between rental(this) or rental with extra e-waste(any time you replace a cheaply made or planned obsolescence product) and it sucks.