> This article does not mention that environment variables are also visible by process in /proc/*/environ (which has restrictive permissions, but is completely visible to root).

He's explicitly not using export, so they won't show up there. Plain variables are not in the environment.

(it's good to bring up this file as well as getting inherited by child processes though)

I believe that unexported shell variables will be visible in /proc/*/mem, so it would be prudent to overwrite then unset them as soon as reasonably possible in their usage.

mem, yes, definitely. I'm not sure how you can protect yourself from that (or root user using ptrace or equivalent debugging tool) though...

Oh, memfd_secret?

       The memory areas backing the file created with memfd_secret(2) are visible only to the processes that  have  ac‐
       cess  to the file descriptor.  The memory region is removed from the kernel page tables and only the page tables
       of the processes holding the file descriptor map the corresponding physical memory.  (Thus, the pages in the re‐
       gion can't be accessed by the kernel itself, so that, for example, pointers to the region  can't  be  passed  to
       system calls.)

Hm, this is interesting. What kernel version did you find this in? Im curious if this is exposed to other languages

From the man page: Linux 5.14.

Before Linux 6.5, memfd_secret() was disabled by default and only available if the system administrator turned it on using "secretmem.enable=y" kernel parameter. [...]

"To prevent potential data leaks of memory regions backed by memfd_secret() from a hybernation image, hybernation is prevented when there are active memfd_secret() users."

I think that once root is the adversary, all bets are off. The simplest being /proc/*/mem or hooking a debugger up to the process and pausing it...

> I’m also intrigued by the potential that type systems have for “tagging” secrets and preventing their propagation beyond where they’re needed

facet (rust) allows tagging fields as sensitive so they won't show up in logs: https://facet.rs/guide/attributes/#sensitive

I'm sure other languages have equivalents but I rarely see this.. for example I was about to say serde doesn't do it, but it looks like it's possible with a wrapper type? https://docs.rs/redactrs/latest/redactrs/

Anyway, this kind of tagging is good, I want more!

PHP has the SensitiveParameter attribute for treating fields/variables as sensitive.

https://www.php.net/manual/en/class.sensitiveparameter.php

I don't get why a bad guy couldn't dump the current log / hash, then load a kernel module that'd just replay the same values whenever someone asks for it? Does the log have a challenge/nonce from the client that'd change the hash everytime it's obtained? (if the client loads their own kernel module they can check it's on the list, but the whole point is about not having to do that, right..)

I had the same problem on our home server.. I just stopped the git forge due to lack of time.

For what it's worth, most requests kept coming in for ~4 days after -everything- returned plain 404 errors. millions. And there's still some now weeks later...

I get a new fingerprint id everytime I refresh the page (firefox, linux) -- so that might be sampling a tiny bit too much. audio and canvas fingerprint are constant though so it's probably plenty enough...

The same applies to macOS. Safari produces a unique fingerprint ID every time, and Firefox also has a different fingerprint ID with every visit.

If the fingerprint ID is unique every time, there is zero possibility of using it for identification.

Very interesting. So this is the battlefield perhaps. Randomly corrupt the data instead of eliminating it?

I think it might be because the performance fingerprints need to be bucketed. If they're too specific you'll never get the same fingerprint twice.

Also convinced they're observing a correlation with this rather than something age specific. It's like exercise, it's really impressive how people who stay active in their late years can still be very fit way into their 80s or 90s, yet if one stops trying it just crumbles away.

Breaking the system is the point! Let them break stuff, you learn when you have to fix it afterwards.

To author -- code sample as images is great for syntax highlight but I wanted to play with the examples and.. got stuck trying to copy the content.

(also expected tesseract to do a bit better than this:

  $ wl-paste -t image/png | tesseract -l eng - -
  Estimating resolution as 199
  const std = @import("std");
  const expect = std.testing.expect;
  
  const Point = struct {x: i32, y: i32};
  
  test "anonymous struct literal" {
  const pt: Point = .{
  x = 13,
  -y = 67,
  33
  try expect (pt.x
  try expect(pt.y
  
  13);
  67);

)

tesseract does well for me...

    const std = @import("std");
    const expect = std.testing.expect;

    const Point = struct {x: i32, y: i32};

    test "anonymous struct literal" {

    const pt: Point = .{
    .x = 13,
    .y = 67,
    };
    try expect(pt.x == 13);
    try expect(pt.y == 67);

The trick is to preprocess the image a little bit like so:

    ocr () 
    { 
        magick - -monochrome -negate - | tesseract stdin stdout 2> /dev/null
    }

Thank you!

Unfortunately I get the same kind of garbage around closing curly braces / closing parenthesis / dots with this magick filter... It seems to do slightly better with an extra `-resize 400%`, but still very far from as good as what you're getting (to be fair the monochrome filter is not pretty (bleeding) when inspecting the result).

I wonder what's different? ( ImageMagick-7.1.1.47-1.fc42.x86_64 and tesseract-5.5.0-5.fc42.x86_64 here, no config, langpack(s) also from the distro)

Yeah, he definitely should have used a code block for the examples. To the author, if you are trying to preserve code formatting and syntax highlighting, there are JS packages that will take care of all of that and produce clean, copyable, well-rendered, accessible code formatting for you.

If you're curious about the legacy link being a 404, the correct link seems to be that: https://tenacityaudio.org/legacy/legacy.html

(found sniffing around https://codeberg.org/tenacityteam/tenacityaudio.org , this 404 was reported on IRC)

My only complain about niri is that after a few weeks without reboot I end up with ~500 terms open, as I often open a new shell to check something, get distracted, and forget about it as it scrolls out of the view... (I usually notice at the 400-500 mark because this machine starts swapping noticeably, and closing it all is a chore that usually ends in pkill without checking...)

Maybe a bit more self discipline would help :)

Wouldn't you have the same problem with changing workspaces? Sounds like you can't keep track of anything not currently present on the screen, which before the overview was a lot harder to deal with. One thing that could help is to create a "temporary terminal" keybinding to launch in floating mode so you'll never forget to close it. Or create a focus-or-launch bind that switches to an existing terminal (tools like Nirius can help minimize scripting). The other thing that may help is adjusting your struts so you can see that windows exist to the left or the right. More of general workflow tip than one related to just terminals.

Yes and no; the difference with workspace is that I was limited to 0-9 with my old wm, so at some point I'd just run out of space and had to close some windows. (well, that, and X11 is apparently limited to 256 clients by default and I never changed that; but I rarely hit that limit :P)

I do have some struts on the side, but I'm basically always juggling with at least 4 or 5 tasks so I always have things open; (I'm not using any right now but I do like the "quake terminals" temporary term styles... But for the same reason it's not always appropriate -- if I didn't close the term, it's because I wasn't done with it and mean to get back to it...)

I started using niri before the overview, I think that could help if I get used to it. But better than overview, what I'd want is something always visible like some horizontal scrollbar indicator to remind me there's e.g. more than 3 windows hidden or something. That might be possible to do with waybar and a bit of glue parsing the windows list...

The latest release exposes information about windows list and positions via API. Someone can write a widget for waybar or any other bar.

Oh! That didn't exist a few months ago, I need to update and do this then :D

I don't use niri but I worked around this problem (feature?) by creating a bash script that by default checks if a terminal is already open and if so, brings it into focus. Then I attach it to my default shortcut to open terminal and then create one more shortcut that opens a new terminal every time. So now, depending on which shortcut is pressed, I can either keep reusing the existing terminal or open a new one. I'm sure we can have a script that can do more fancy logic like allowing new terminals upto a given number and after that just bring the latest one into focus. Plenty of possibilities.

I have a script that allows searching for windows based on title; so e.g. if I know I had a shell open in directory X I could search for that and jump to it... But in practice I quickly have 5+ shells in a directory once I start working on something and at this point my script doesn't let me differentiate between these easily enough to be useful.

Hmm, perhaps that could be made more interactive and allow cycling through these without closing the search overlay... I'll give that a try! :)

I guess you could do this:

    echo "TMOUT=$(units -t '7 days' seconds)" >> .bashrc

If a shell has been sitting at the prompt for 7 days with no input, it's probably OK for it to close. I'm sure it'll be wrong sometimes, but it seems less bad than pkill en masse.

that is actually dream come true... let's keep everything open always :)

and then you reboot the machine with full session restore working (whenever that's available for wayland) and get 500 terminal windows opening at the same time :)

This is what we all want, to be in control. I am OK to make a mess sometimes as long as it is my mess not because of magical system. So yeah I would be OK.

Some kind of alert task that would tell you you have window open that you didn't visit in days would probably also be useful to your point.

I am not against it, just I can see positives in this. This is like tmux without tmux.

Oh, i actually agree with you, I was more concerned about the suprise abd amusement of seeing that amount of windows pop up out of nowhere. Though, I do wonder how well a linux computer will deal with so much forking, if it freezes the machine for a minute it would be rather bad, but maybe linux and wayland are mature enough to not freeze and spawn all that in like a second or so