honorable mention to "In this image we can see a poster. On the poster we can see some text and a picture of a ship."

in awe of some truely horrible image descriptions I've seen on here today

the best one of all consisted of: "image/jpeg"

#til that my aunt's husband's father came up with the jingle "snap crackle pop, rice crispies"

#Amazon has made a statement about how they will prevent the Bell riots.

All hail our AI overlords.

Thanks Amazon, I definitely wanted to quiz chatgpt on AI trick questions rather than search product reviews for actually useful information.

got some solar powered path lights (motion sensing) a few years ago and most of them have died

I assumed it was dead batteries or failed solar panels.. but the panels are still working, the battery was at 1v but I recharged it to 3v and it works fine, can run the light.

The charge circuit is only producing 1v from 5v input for some reason. Interesting failure mode.

just made a hard link to a symlink and... I'm never gonna find the bottom of unix am I?

lrwxrwxrwx 2 joey joey 12 May 3 11:18 y -> foo

Early start to river swimming season.

Our deck planter box grape vine is on its third year of growth.

It looks like there might be grapes this year.

We went with a Reliance seedless grape mainly because it can usually fruit without the use of chemicals.

The post Grapes without chemicals first appeared on WetKnee Books.

Last quote I got for fiber involved a laughing suggestion of a $20k installation fee..

Applied for fiber from a coop that was founded to serve a county in the next state over, but has been expanding here for several years and now claims they can service my address.

(they haven't seen my 1 mile driveway yet..)

A nonprofit would be quite a leg up from starlink.. Not to mention symmetric 1gbps.

Clearly this would be something for the git mailing list. Except I'm building a gitremote-helper that is targeting working with existing git. So I've already implemented a workaround. Thus motivation for repeatedly rebasing C patches over email is not large.

why does #git when pushing to a remote helper, first "list" the remote, then send the helper a "push", and only *then* notice if there's a non-fast-forward and claim the push has failed?

This seems to mean every remote helper has to detect non-fast-forward pushes and reject them, redundantly to git's own detection of the same thing.

(See for example git-remote-gcrypt documenting this as "A longstanding bug is that every git push effectively has a --force.")

I encourage making websites return jwz balls when HN retitles your stuff. I assume JWZ is ok with being a CDN for this purpose.

Hacker news adds a question mark to "The man who killed google search" to make it more "accurate" despite not having read it (or even AI summarized it I guess?)

Meanwhile, Metafilter shows me again why I love it despite itself.

The reverse engineering of the JS they're doing is particularly amusing. Like, it contains 679 embedded javascript libraries and all of their licenses, and 1 mb of every load is used to send those licenses over the wire.

It's been illuminating to watch #starlink's web interface bit rot over the past couple of years. Until last month it rotted away entirely, with the device serving up only a logo.

Amusingly some users were able to restore the old web interface, which still works because the underlying data is still being provided (and will be probably since the phone app uses the same data source).
https://github.com/iam-TJ/open-dishy/

Now when I go to dishy.starlink.com, it's running on my raspberry pi.

Voyager is a bit more V'ger from today

Literally had to go find a blurb that was like "Die Hard meets The Martian--with a dash of Knives Out" to purge that previous blurb from my mind.

"highly commericial" wtf?

editing a pdf form in firefox, what is this dark magic?

I’m thrilled to announce that our incubation handbook is now in print! A very skilled intern helped buff up the text over the winter and the result is ready to make your next hatch a major success.

(The ebook is a bit spiffier also, with the same information but more polish and a fancier cover and title.)

Here are some of the reviews of the first edition if you need more incentive to check it out:

“I have had problems with incubating chicks, getting low to no hatch, and high hatch mortality. All of the info in this book makes great sense! This helped me a lot to fix ALL of my hatch problems.” — sunnyweller

“I especially found the “helping chicks hatch” section very helpful. Followed the instructions and saved two chicks!” — Keaokun

“My first attempt at incubating was a dismal failure. I only hatched 6 of 19 eggs. Two of those had facial and beak deformities. This little ebook was so helpful and I was able to pinpoint – many – things I had done wrong.” — V. Schafer

“Awesome book, well written. Not too basic nor too much extraneous detail.” — chem girl

I’m hoping to enjoy another round of intern magic this summer, so I’d love to hear which ebook-only title you’d most like to have available in print. Or perhaps you’d prefer us to turn our newest video course into an ebook and paperback? Please comment and let me know what you want!

The post Incubation handbook now in print! first appeared on WetKnee Books.

copyright question it seems worth pondering:

If I use a false persona to get malicious code into an open source project, and along the way include some good code to cover my tracks, and I mendaciously comply with all the standard stuff needed to get my code into the project (copyright statements etc), then is that good code actually freely licensed?

mostly finished rebootstrapping from source after post-con crud

We’ve written in the past about our mushroom experiments, which mostly centered around using plug spawn in logs. So I was thrilled when our local library offered an opportunity to try something a little different — sawdust spawn.

(Yes, we do have the best library around. Yes, they did let us take home an inoculated shiitake log of our very own.)

Pros and cons of sawdust spawn

As best I can tell, the only real downside of using sawdust spawn is that you need to buy an inoculation tool. At $45 per tool, that means sawdust spawn makes the most sense for folks who intend to inoculate at least 36 logs (although you don’t have to do them all at once, of course). My math in today’s dollars:

• Sawdust spawn: about $1 per log in spawn cost
• Plug spawn: about $2.25 per log in spawn cost

In addition to long-term price savings, other benefits of using sawdust spawn include:

• Your logs will produce mushrooms faster (in 5 to 12 months instead of 9 to 18 months).
• I actually found inoculation with the sawdust tool gentler on my wrists (no hammering!).

Other inoculation innovations

Other than the inoculation tool, using sawdust spawn is pretty much the same as using plug spawn. But I thought you might enjoy seeing our teachers’ entire process since it is definitely better than ours!

First the infrastructure: They built tables with little wooden cradles at intervals to hold the logs in place. That means the only time you really need a second set of hands is when drilling the holes.

Also note the measuring stick with the spacing information on it. No laborious hand-measuring each log!

Another innovation is the use of an angle grinder rather than a drill gun. Mark shared a video in which you can see how much faster this is than what we’d done in the past.

(Do be careful though. I could see someone drilling through their hand with this setup.)

After the holes are drilled, it’s time to insert the spawn. Sawdust spawn comes in a block like the one shown above. You break it up with your hands then scoop some of the loose sawdust out into an empty yogurt container (or something similar).

Next, bang the inoculation tool into the container a few times to fill it with spawn. Place the tool over the hole and depress the button at the top to insert spawn. The goal is for the spawn to fill the hole up to about the bark level.

After that, all you need to do is wax over each spawn-filled hole. In the past, we’ve used beeswax from local hives, but apparently any food-safe wax works. Our teachers were using paraffin, melted then daubed on with cute little brushes. But they mentioned that there’s a new kind of wax, primarily used with plug spawn, that you can wipe on cold with your finger.

After that, it’s the usual waiting game (with the side note that, since we now live in an area with less extreme precipitation than we used to be located, we need to remember to water our log if we don’t get at least an inch of rain per week).

We haven’t had productive mushroom logs since moving to Ohio, but remembering how fun and easy inoculation was put the process back on my radar. Maybe next year we’ll push wildcrafting mushrooms onto the back burner and inoculate more logs.

About our teachers

I want to end with a huge thank you to Soulshine Acres for sharing their expertise with us. They’re a frequent vendor at the Athens, Ohio, farmer’s market if you want to check some of their mushrooms out. Or just follow them on instagram using the link above to learn about their forest farm, full of over 400 mushroom logs.

The post Inoculating mushroom logs with sawdust spawn first appeared on WetKnee Books.

it was also serving the front page as a 404 for the javascript linked from the front page yesterday, which is a very nice level of breakage indeed

gotta give #starlink praise where due, by removing the proprietary web frontend from their starlink terminal, they drive free software development in the space of seeing basic obstruction maps, knowing when your starlink is obstructed or the network is otherwise down, etc

Making even 404 pages the same useless logo as the front page is also a strong choice.

https://github.com/sparky8512/starlink-grpc-tools

Already missing #distribits, hoping we do it again sometime

appimage mounts a clipboard, wtf?

This is my and @mih and Timothy Sanders's result of the #distribits hackathon, design for #gitAnnex special remotes to support storing git repositories. We improved on git-remote-datalad-annex significantly I think and I hope to implement this as part of #gitAnnex.

https://git-annex.branchable.com/todo/git-remote-annex/

generation of the #distribits video archive has started, and since we're using a #gitAnnex repository it's a collaborative public process which will culminate in a redundantly mirrored archive with rich metadata.

Here the day long youtube videos are being cut into clips https://github.com/distribits/distribits-allvideos/pull/2

I woke up refreshed home at last, ran a git-annex get, checked out the clips branch, ran the cut command, and have every talk available to review.

Last sight of Dusseldorf. Great town!

Performed a ceremonial tagging of Datalad 1.0 at the conclusion of #Distribits

"an octopus merge of 40 thousand branches" -- #datalad people are wild #git

Streetcar I caught to the conference this morning.

The NYT today demonstrates they can't comprehend an xkcd cartoon.

Not that I didn't already understand that about their tech reporting.

Slides depicting a massive ecosystem with #gitAnnex somehow central to it is a new thing I'm collecting. Scientists produce great slides like this. (And other great things.)

When you write a software to manage your cat photos and it gets used for brain slicing scans to the tune of 2 petabytes brain/year. #gitAnnex #distribits

looking forward to some strolls along the Rhine now that it's finally stopped torrentially raining

AMAZING day at #distribits !

Here's my talk in the day 1 recording, "git-annex is complete, right?"
https://youtu.be/BwRy3z_hQ70?t=3412

Was also in a panel session 20 minutes after that. And there are many many other great talks in there. Can't wait until tomorrow

#gitannex

Drilling holes in mushroom logs just got a lot easier and faster with this new shitake drill bit.

You will also need the angle grinder drill chuck adapter.

More details from a shitake log workshop will be ready for next week.

The post Shitake log inoculation video first appeared on WetKnee Books.

new "Plans" section on https://tukaani.org/xz-backdoor/

"I plan to write an article how the backdoor got into the releases and what can be learned from this. I’m still studying the details.

xz.git needs to be gotten to a state where I’m happy to say I fully approve its contents. It’s possible that the recent commits in master will be rebased to purge the malicious files from the Git history so that people don’t download them in any form when they clone the repo. [...]"

#xz

Jia Tan's history of commits on #xz suggests that every png file in gcc or apache or whatever is a possible attack vector now.

https://joeyh.name/blog/entry/reflections_on_distrusting_xz/

Was the ssh backdoor the only goal that "Jia Tan" was pursuing with their multi-year operation against xz?

I doubt it, and if not, then every fix so far has been incomplete, because everything is still running code written by that entity.

If we assume that they had a multilayered plan, that their every action was calculated and malicious, then we have to think about the full threat surface of using xz. This quickly gets into nightmare scenarios of the "trusting trust" variety.

What if xz contains a hidden buffer overflow or other vulnerability, that can be exploited by the xz file it's decompressing? This would let the attacker target other packages, as needed.

Let's say they want to target gcc. Well, gcc contains a lot of documentation, which includes png images. So they spend a while getting accepted as a documentation contributor on that project, and get added to it a png file that is specially constructed, it has additional binary data appended that exploits the buffer overflow. And instructs xz to modify the source code that comes later when decompressing gcc.tar.xz.

More likely, they wouldn't bother with an actual trusting trust attack on gcc, which would be a lot of work to get right. One problem with the ssh backdoor is that well, not all servers on the internet run ssh. (Or systemd.) So webservers seem a likely target of this kind of second stage attack. Apache's docs include png files, nginx does not, but there's always scope to add improved documentation to a project.

When would such a vulnerability have been introduced? In February, "Jia Tan" wrote a new decoder for xz. This added 1000+ lines of new C code across several commits. So much code and in just the right place to insert something like this. And why take on such a significant project just two months before inserting the ssh backdoor? "Jia Tan" was already fully accepted as maintainer, and doing lots of other work, it doesn't seem to me that they needed to start this rewrite as part of their cover.

They were working closely with xz's author Lasse Collin in this, by indications exchanging patches offlist as they developed it. So Lasse Collin's commits in this time period are also worth scrutiny, because they could have been influenced by "Jia Tan". One that caught my eye comes immediately afterwards: "prepares the code for alternative C versions and inline assembly" Multiple versions and assembly mean even more places to hide such a security hole.

I stress that I have not found such a security hole, I'm only considering what the worst case possibilities are. I think we need to fully consider them in order to decide how to fully wrap up this mess.

Whether such stealthy security holes have been introduced into xz by "Jia Tan" or not, there are definitely indications that the ssh backdoor was not the end of what they had planned.

For one thing, the "test file" based system they introduced was extensible. They could have been planning to add more test files later, that backdoored xz in further ways.

And then there's the matter of the disabling of the Landlock sandbox. This was not necessary for the ssh backdoor, because the sandbox is only used by the xz command, not by liblzma. So why did they potentially tip their hand by adding that rogue "." that disables the sandbox?

A sandbox would not prevent the kind of attack I discuss above, where xz is just modifying code that it decompresses. Disabling the sandbox suggests that they were going to make xz run arbitrary code, that perhaps wrote to files it shouldn't be touching, to install a backdoor in the system.

Both deb and rpm use xz compression, and with the sandbox disabled, whether they link with liblzma or run the xz command, a backdoored xz can write to any file on the system while dpkg or rpm is running and noone is likely to notice, because that's the kind of thing a package manager does.

My impression is that all of this was well planned and they were in it for the long haul. They had no reason to stop with backdooring ssh, except for the risk of additional exposure. But they decided to take that risk, with the sandbox disabling. So they planned to do more, and every commit by "Jia Tan", and really every commit that they could have influenced needs to be distrusted.

This is why I've suggested to Debian that they revert to an earlier version of xz. That would be my advice to anyone distributing xz.

I do have a xz-unscathed fork which I've carefully constructed to avoid all "Jia Tan" involved commits. It feels good to not need to worry about dpkg and tar. I only plan to maintain this fork minimally, eg security fixes. Hopefully Lasse Collin will consider these possibilities and address them in his response to the attack.

in a cafe in germany, wide awake, 16 hours of sleep seems to have beaten jetlag and accumulated xz sleep debt

I can't wait to learn about how a lot of people are using #gitAnnex tomorrow at the Distribits conference!

arrived in Dusseldorf for #distribits

ah europe, been too long.. also this is very very europe

"Selfies please" - gate agent re facial recognition. 2024

Maybe #xz was a state sponsored attack against #aprilfoolsday

Been a while since I read a news article that quoted me as a Debian developer..

Besides that innaccuracy, I think this is a pretty decent article.

https://www.thestack.technology/xz-utils-github-repository-disabled-as-linux-maintainers-assess-blast-radius-of-backdoor-earlier-commits/

special shout out to whoever in the reversing channel is using alias "Jia Tan"

closing all my social media before I go thru TSA security because it looks like Mr Robot was here

my fun little surprise today was noticing liblzma in `ldd git-annex`

Pulled in via libmagic, which on Debian is patched to link to liblzma.

git-annex can be built without that (-f-MagicMime) but it does add a nice feature.

Anyway, interesting to know that Jia Tan's code is running in my processes forever unless xz gets reverted to the 2021 version.

Some theories about Jai Tan's location based on timezones in commits, like https://rheaeve.substack.com/p/xz-backdoor-times-damned-times-and/comments are relying partly on the commits in these series that were likely `git am`ed.

That makes those theories considerably shakier, although not every timestamp mentioned in that article is in these series. #xz

To find these, used:

git log --pretty=raw | perl -e 'while (<>) { if (/^commit /) { $ps=$s;$s=$_ }; if (/^author .* (\d+) [-+]\d+$/) { $pa=$a; $a=$_; $pad=$ad; $ad=$1; } if (/^committer .* (\d+) [-+]\d+$/) { $pc=$c; $c=$_; $pcd=$cd; $cd=$1; if (defined $pcd && defined $pad && $pcd==$cd && $pad==$ad) { if ($la ne $a && $lc ne $c) { print "\n" } ; $la = $a; $lc = $c; if (! defined $ls || $ls ne $ps) { print "$ps$pa$pc"; $ls=$ps}; print "$s$a$c"; } } }'

urk old habits die hard

Checked all xz commit timestamps for similar patterns. first is a series of commits by Jia Tan on Jan 19, then another Jan 22, then Lasse has a series on Feb 9, then a long series that includes the commits mentioned above, then 3 more series by Lasse on Feb 17 and Feb 29. This certainly seems unusual.

but, I do find similar things in git.git history, Junio has a workflow that results in that legitimately

This suggests to me that xz's git workflow changed in January.