Lair Of The Multimedia Guru

I was looking for a way to securely manage my passwords, anything storing my passwords with a 3rd party or all accessible to my computer fail IMHO. Also it had to be practical, something limited to 5 passwords is not. Be convenient, something where one would have to search for a password in a list by hand fails that. And it needed to have a screen so one knew what one approved. A simple one button USB stick does not qualify either as one does ultimately not know what one actually approved. The only device i could find was the mooltipass. So i bought one. It is a cute little thing storing all passwords both securely and also conveniently. And being a nerdy geeky person, i of course had to play with and analyze it. The first thing that sprang out to me was its random number generator

Can we exploit it ?

So i looked at its random number generator until i found something. It uses the 2 LSB of each of the 3 axis of an LIS2HH12 accelerometer. This generator was tested with the DIEHARDER battery of tests by its creator before me. I was at first not able to run the DIEHARDER tests because they needed more random data than the device could generate quickly. I tried various tests, simple things like simply trying to compress the data showed no anomalies. The first anomaly i found, i believe was through looking at the frequency spectrum in audacity. To my eye it looked like there was a bias between high and low frequencies. The next step was checking the correlation of various bits. And indeed when one looked at 2 bits and the previous 2 bits from the same channel They where equal 3% more often than they should be. I guess i could have stoped here, but i didn’t :) So i looked at the distribution of matching bits, (3% of these shouldn’t be there and we dont know which of 100 are the 3 bad ones). These 3 could be randomly distributed of course. But by now i had enough data to run some of DIEHARDER and while most tests passed, some of its tests failed for me. I have to say though little things in the command line of DIEHARDER can lead to unexpected results.

The original findings on the 3% anomaly

I simply counted the number of times each 2bit matches the previous
2bits of the same channel and this occurs about 3% more often than it should.

With 1 mb of data:
Channel 0 [1.026829 : 1.980986 : 0.992185]
Channel 1 [1.031329 : 1.978283 : 0.990388]
Channel 2 [1.039171 : 1.974176 : 0.986653]
Average   [1.032443 : 1.977815 : 0.989742]
All 3     [0.968019 1.010415 1.052310 1.111489]

/dev/random
Channel 0 [1.000765 : 1.998530 : 1.000705]
Channel 1 [0.997429 : 2.001644 : 1.000927]
Channel 2 [0.997357 : 2.003375 : 0.999268]
Average   [0.998517 : 2.001183 : 1.000300]
All 3     [1.001617 0.999233 0.997958 0.995425

This allows relatively reliably distingishing the mooltipass random numbers from /dev/random with 10kb of data

Periodic anomalies

Looking again at the randomdata. The 3% extra repeats within a channel occur 32 samples apart (that is 24 bytes in the stream or 192 bits). These locations sometimes shift around but preferably occur at indexes 31,63 and 95 of the 96 sample block. When such a run of anomalies breaks from teh same index, the new index tends to be the next in the set {95,63,31}. With these patterns it is possible to reliably distinguish as little as 100-200 bytes from random data. That said, the randomness of this is still plenty for a password and the average human would be way worse generating random data. Care though may need to be applied if this is used for other purposes than passwords. For example DSA signatures are notorious for being sensitive to biases in the used random number generator. I reported the anomalies in the RNG in January of 2023. It was fixed on Apr 18th 2023 with 49359dfc52cdfe743000ac512092085328d5f15b. Software to detect the specific pattern reliably as well as 2 small test samples is availble at randomtests

The original findings on perodic anomalies

Heres how this compares to /dev/random
dd if=/dev/random of=/dev/stdout count=1 bs=1000 status=none | ./mooltitestwalker
mooltiness:     0.89 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=/dev/random of=/dev/stdout count=1 bs=10000 status=none | ./mooltitestwalker
mooltiness:     0.25 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=/dev/random of=/dev/stdout count=1 bs=100000 status=none | ./mooltitestwalker
mooltiness:     0.04 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=/dev/random of=/dev/stdout count=1 bs=1000000 status=none | ./mooltitestwalker
mooltiness:     2.99 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=/dev/random of=/dev/stdout count=1 bs=10000000 status=none | ./mooltitestwalker
mooltiness:     0.08 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

and now the random data from mooltipass

dd if=~/mooltirandom.bin-copy of=/dev/stdout count=1 bs=1000 status=none | ./mooltitestwalker
mooltiness:     3.16 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=~/mooltirandom.bin-copy of=/dev/stdout count=1 bs=10000 status=none | ./mooltitestwalker
mooltiness:     4.21 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=~/mooltirandom.bin-copy of=/dev/stdout count=1 bs=100000 status=none | ./mooltitestwalker
mooltiness:    12.91 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

dd if=~/mooltirandom.bin-copy of=/dev/stdout count=1 bs=1000000 status=none | ./mooltitestwalker
mooltiness:    37.46 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7

dd if=~/mooltirandom.bin-copy5 of=/dev/stdout count=1 bs=10000000 status=none | ./mooltitestwalker
mooltiness:   115.95 expected: < 1 in 68% cases, < 2 in 95%, < 3 in 99.7%

As you can see with just 1000 bytes we are already more than
3 standard deviations away from random data. And after that it very quickly
becomes something that a random number generator would not generate in the lifetime of
the universe not even if you fill the whole universe with random number generators should
you see this sort of statistics once

Heres the test results for 100,200,300,400,500 bytes with mooltitestcycler

for i in `seq 100 100 500` ; do dd if=~/mooltirandom.bin-copy of=/dev/stdout bs=$i count=1 status=none | ./mooltitestcycler ; done
moolticycles:     3.00, this or larger is expected 0.27 % of the time in random data.
moolticycles:     4.58, this or larger is expected 0.00046 % of the time in random data.
moolticycles:     6.00, this or larger is expected 2E-07 % of the time in random data.
moolticycles:     6.93, this or larger is expected 4.3E-10 % of the time in random data.
moolticycles:     7.75, this or larger is expected 9.5E-13 % of the time in random data.

Same but with another testsample to make sure this is not a one off

for i in `seq 100 100 500` ; do dd if=~/mooltirandom2.bin of=/dev/stdout bs=$i count=1 status=none | ./mooltitestcycler ; done
moolticycles:     3.00, this or larger is expected 0.27 % of the time in random data.
moolticycles:     4.58, this or larger is expected 0.00046 % of the time in random data.
moolticycles:     6.00, this or larger is expected 2E-07 % of the time in random data.
moolticycles:     6.93, this or larger is expected 4.3E-10 % of the time in random data.
moolticycles:     7.75, this or larger is expected 9.5E-13 % of the time in random data.

In fact i notice now the results are exactly the same, interresting
cmp  ~/mooltirandom2.bin ~/mooltirandom.bin-copy
/home/michael/mooltirandom2.bin /home/michael/mooltirandom.bin-copy differ: byte 1, line 1


heres the control test with /dev/random
for i in `seq 100 100 500` ; do dd if=/dev/random  of=/dev/stdout bs=$i count=1 status=none | ./mooltitestcycler ; done
moolticycles:     0.00, this or larger is expected 1E+02 % of the time in random data.
moolticycles:     0.31, this or larger is expected 76 % of the time in random data.
moolticycles:     0.58, this or larger is expected 56 % of the time in random data.
moolticycles:     0.44, this or larger is expected 66 % of the time in random data.
moolticycles:     0.77, this or larger is expected 44 % of the time in random data.

and a bigger sample to show the runs:

dd if=~/mooltirandom.bin-copy5 of=/dev/stdout bs=2000000 count=1 status=none | ./mooltitestcycler
Run 1731 at phase 31
Run 7496 at phase 95
Run 3323 at phase 63
Run  196 at phase 31
Run  195 at phase 95
Run 3540 at phase 63
Run 2459 at phase 31
Run  777 at phase 95
Run  775 at phase 63
Run  195 at phase 31
Run  583 at phase 95
Run  778 at phase 63
Run 1585 at phase 31
Run 1126 at phase 95
Run  971 at phase 63
Run 5047 at phase 31
Run 7141 at phase 95
Run 1741 at phase 63
Run 4643 at phase 31
Run  197 at phase 95
Run  577 at phase 63
Run  197 at phase 31
Run 2907 at phase 95
Run 4040 at phase 63
Run 1572 at phase 31
Run  196 at phase 95
Run 2903 at phase 63
Run 1355 at phase 31
Run  195 at phase 95
Run  196 at phase 63
Run  584 at phase 31
Run  143 at phase 95
Run   51 at phase 63
Run  195 at phase 31
Run 3099 at phase 95
Run  196 at phase 63
Run 1164 at phase 31
Run 2445 at phase 95
Run 2589 at phase 63
Run 4553 at phase 31
Run 7145 at phase 95
moolticycles:   499.67, this or larger is expected 0 % of the time in random data.

Shaken not Stirred

A 2nd issue i found and reported on 7th feb 2023 is that when the device is violently shaken, the accelerometer saturates and clips at 2g, this makes the 2 LSB of the affected channel(s) be 00 or 11 more often than expected in a random stream of data. So please dont use the mooltipass while doing high G maneuvers in a fighter jet or any other activity that subjects it to high g forces. Also with some effort one can shake a 3 axis accelerometer so that all 3 axis clip at the same time. There also may be a delay between the generation and use of random data. Ideally when the full 16bit sample clips it should be discarded and not used. While discarding one kind of sample that was equally frequent, introduces a bias, the clipping cases are not equally frequent. They either do not occur at all in a still environment or occur disproportionally frequent.

Random now?

Except these, i found no further flaws in the random data. Personally i would recommend to use some sort of hash or other cryptography to mix up the accelerometer bits. Heating or cooling (in my freezer with long USB cable) the device did not introduce measurable bias and also feeding ~60 mega byte stream of data into the PRNG NIST-Statistical-Test-Suite did not show any anomalies after the fix. Of course one can only find flaws in such data streams, never proof the absence of flaws. Also it must be said that i could not find any reference by the manufacturer of the chip to randomness of the LSBs. So while AFAIK many devices use accelerometer data as source of random data, there seems no guarantee that a future revision of that chip doesn't produce less random bits. What i can say, is thus just about the device i looked at and for that, the random data is much better than what a person would generate by "randomly" pressing keys. People are very biased in what characters they use in passwords even when they try to be random. Also passwords are generally too short for this anomaly to allow distinguishing 1 password from another with a unbiased RNG. A password that one believed contained n*192 bits of entropy really only contained n*190 before the fix. All this assumes the device is not violently shaken while used.

Audacity spectra

Took me a bit to find and restore the original spectrum i saw. While doing that i also noticed that using signed 8bit results in a spectrum biased the other way. The original ones are unsigned 8bit.

mooltipass pre fix spectrum	/dev/random control spectrum	mooltipass post fix spectrum

Audacity spectra with more data and in signed 8bit ints

recreated mooltipass pre fix spectrum	/dev/random spectrum	mooltipass post fix spectrum

Dieharder testsuite

Ill write a separate article about dieharder later, the thing is finicky and this is already quite complex

Updated this article multiple times (last on 2023-05-24) to include more details, pictures and minor corrections
Full disclosure, i was offered a reward for finding and reporting the bug.

Today i learned a new feature of the EU Schuko plug.
I moved some stuff to a different apartment, plugged it in and slowly build the feeling something wasn’t quite right. Some electronics behaved a bit odd, somehow grounded things didn’t feel quite grounded.
So i connected a DMM between the grounds of 2 plugs

and

and between we have

ehm, 126 Volts
On closer inspection we can see the ground lead on the wall outlet has been painted over. Sure thats a rare exception, lets look at the other lead

sure its not the 2nd plug too that our green wire eventually was connected to

sure its not all plugs on that wall

whatever, cleaning that off and retesting


Problem solved, lets pretend we didnt notice this EU population control feature ;)
Having the ground leads exposed so that morons can paint over them and then anything pluged in simply has no ground connection. Bad design, simply bad design.

The key iam using everyday is really becoming old. OTOH the new key iam using for signing my git commits isnt really good as a general key as it needs to be available on the machiene i work on to sign rebased commits and all that. So its more “my git development box” key than mine.
And i have that cute little ledger that has a gpg plugin. So i thought, thats something i should look into. Yeah, or maybe i shouldnt have done that.
It supports ed25519 and cv25519. So i created one and signing worked, decryption failed with a gpg: public key decryption failed: Card error. So i tried again with default options which generates the encryption key apparently on the host backs it up and uploads. That worked fine, it asked for a password to encrypt the backup, signing worked decryption worked, all was fine, or was it? I had set the ledger to require a button before decryption and it didnt. Hmm, i started to have a odd feeling. I disconnected the ledger and tried again, yes it still decrypted it. Was it caching the key or passphrase ? i killed gpg-agent, it still decrypted it. It took me a moment before i fully believed it but yes there was a unencrypted private key where a stub should have been pointing to the ledger.
More testing showed that the ledger works fine with RSA and NISTP256 keys for decryption and RSA and ED25519 for signing. Though it is not able to generate NISTP256 keys, or at least not when i tried, these need to be copied onto. RSA upto 4096 can be generated on the thing if one has patience. CV25519 seems not to work no matter what i tried even though it seems to be supposed to be supported.
Now, i have setup mine (and the public keys are below if you want to send me something secret) but the whole experience leaves me with afterthoughts about wanting to use this. The way this failed and the thing that the source code sometimes speaks of “ed2559” and sometimes of “ed255519” leaves me with some desire for a different device for storing my key on in the long run. Not that any of this is pointing to any real security issues once one got a working key on it and made sure no plain copies remain.

-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEY73h4hYJKwYBBAHaRw8BAQdAsSAAq3LxY0Fcw29nsG39GDF4CMgAoDV8Qb27
aHh2obq0MU1pY2hhZWwgTmllZGVybWF5ZXIgPG1pY2hhZWwta2V5MkBuaWVkZXJt
YXllci5jYz6IlgQTFggAPhYhBFwRfsTnHWQ2HRuoQq1G6+FU56XXBQJjveHiAhsD
BQkDwmcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEK1G6+FU56XXPyoBAJTK
YelgVZBdkSK0zo4IYqyXR+dUJMjT8SlXvAxsbHVwAP97VsXCcXWxH6oPR/LKGJgA
PDO+X5iy6pDFO6eQNmzgA4hdBBMRCAAdFiEEn/ISixR+9nMLrfEzYR7HhwQLD6sF
AmO96VUACgkQYR7HhwQLD6uDZQCfTc2K/GL0A6wi5BIGuQMM5iYMX2sAnAvxsZfA
bUjviZzbdsuCplgQduG7uFYEY73h4hIIKoZIzj0DAQcCAwS96wJJL1mSdwT94Atc
c2Q0r1O4vIkEIqnGDLGXGu3egxWzStCjojpCg+ELEDjU2rxtu51GzYLQUTazEzWU
Ql+IAwEIB4h4BBgWCAAgFiEEXBF+xOcdZDYdG6hCrUbr4VTnpdcFAmO94eICGwwA
CgkQrUbr4VTnpdflbQD+KCouQqLQ6Gl9bNrPZfXf8055b6qVtfzsQzQF+LOeo4EB
AK+6cxLVHB2jcYyvlIv73R8JWvNHcxE/3mDEYKiP3D0J
=IkKl
-----END PGP PUBLIC KEY BLOCK-----

I was playing around with a VM remotely. Without much thinking i setup a VPN and hit enter after the connect command.
It worked fine, or rather i suspect it did because it blocked the connection to the router through which i accessed it.

Now I could have gotten in the car and driven over to the thing or just ignored it as it had no real use anyway. But it turns out it was too hard for me to just ignore it. That had to be fixable remotely.
I would have expected virtualbox to have some sort of serial console or something like that. And iam sure it has a host of ways to recover this nicer but what i found first and that worked was this:

vboxmanage  controlvm (name) screenshotpng this.png ; ffplay this.png
vboxmanage  controlvm (name) keyboardputstring "foobar"
vboxmanage  controlvm (name) keyboardputscancode 12 34 56

With these we can look at the screen and we can enter things, thats more than enough to recover it. One thing to keep in mind is that the keyboardputstring commend seems to assume a us keyboard layout.
The 2nd thing to keep in mind if you use this for a similar case, you want to make sure you do not put any passwords into any shell history files. At least not without realizing it and changing the password then

Why Crypto?

With the IPFS support in FFmpeg and the discussions surrounding it. Several people stated their dislike for crypto, for NFTs and stated how its harmful and full of scams.
I disagree, Or rather I think people are seeing the “What” today but are missing the “Why” tomorrow.

Why Crypto?!

For me what i see in crypto is giving power over assets back to the people.
Today, everything is a fight of government vs people. Free speech vs censorship. Privacy vs logging and spying. Self defense vs. outlawing tools to defend oneself. And in the future with advances in gene editing control over ones own body will increasingly also get added. But back today and also with money the people are slowly loosing control to the government. Cash is slowly replaced by fully controllable and logable transactions, money printing and taxes are generally fully controlled by the government already. What you can invest in as a “non accredited” investor also is tightly controlled.
Lets look at money printing alone. That on average causes a 50% loss of value in stable currencies like the USD or EUR every 20 years. That means money literally has a half life time of 20 years in stable western economies. And that doesn’t even account for the recent money printing activities of the last years. You may have noticed inflation recently maybe ? Thats the result not of a war its simply because of all the extra money that was created.
Now with crypto, the government has no control over the inflation anymore. Bitcoin might be worth a lot or a little but is not decaying like USD does. And gold even gold inflates as new gold is mined.
And while with cash, any money you own you can give anyone you choose, as cash disappears and is replaced by government controled digital forms of the USD. You also will loose the ability to do with it what you want. OTOH with crypto you can send it to any wallet. And you can set nearly arbitrary rules with smart contracts. It simply returns the power over wealth and assets back into the peoples hands.

Will it go up

I dont know and I don’t really care. Most of the crypto i have originated from payment for a little FFmpeg work very long ago, ive exchanged some of this in other coins and other crypto stuff but i never took it out of crypto and i have no intend to ever.

NFTs?

Theres 2 things about NFTs, the NOW and the Future
NOW, NFTs are used as a way to raise money, many of the bigger projects are shady. Its expected, the more a project promises the more people want it but also the more its all a lie. I would not be surprised if many of these will go to practically 0 value. Then there are the NFTs from honest people who want to start a business and try to use it for getting initial capital some of these pass 100% of the decisions what to do with the collected money to votes by the NFT holders. There are also art and collectible NFTs and a big overlap between all this. I don’t know what will become of all this. The idea to raise money and then have the investors be 100% in control of the business sounds not fundamentally bad to me. Will this survive regulation? I do not know …
And then theres the FUTURE. NFTs can represent anything, a specific car, a specific house, a specific contract you have with an insurance.
In such a world one could sell, buy, exchange and rent houses, cars, contracts in a 100% secure, 100% undisputed and very simple way. Using the “blockchain” to represent all real world assets is an intriguing future, it has interesting potential. I don’t know if that is something that will ever happen but it surely would be a revolution for alot of things.

For a long time i used cheap wired logitech or microsoft mice and that was ok-ish. But from time to time one needs to buy a new mouse for a new computer, because the old is so dirty its disgusting or the really rare that it stopped working 100% reliable. So for some forgotten reason i bought a new one and my mistake here is that i trusted the amazon ratings (never do that). So i got a “noname == tecknet” mouse, it was cheap had more buttons than the cheap logitech one. It even was the “Amazon choice” for wired mouse. How it got that rating, i can not comprehend. The problem with this mouse is it simply does not work reliable. You turn the scroll wheel one way and it sometimes registers that and sometimes registers the opposite direction.
So as that thing was just annoying, i picked a new mouse again and using my brain slightly more this time, i concluded that any gaming mouse must be reliable as gamers dont like loosing from lost or misread buttons. So i choose based on specs and price a corsair gaming katar pro xt. Nice mouse nice hardware. linux support well, kind of. It works fine out of the box if you like your computer looking like a Christmas tree.

Switching off that LED

My first thought was of course that there must be a tool on linux to turn this off. I failed to find it though.
So the next was screwdriver / soldering iron but that was really not feeling right.
So i spend several hours implementing enough support in ckb_next to adjust the LED for this mouse. This would have been quite trivial with a windows box running the official driver and listening to it but i didnt had a windows machine, so randomly reading and writing things to the mouse was the way to go. This was especially fun as the mouse remembers its settings when disconnected. So if you successfully set something you have an incentive to undo that if you want it working as before. I didnt destroy the mouse no, basically blindfolded stabbing it with random writes allowed me to identify a few more fields of what seems called the bragi protocol. So the protocol header now lists the fields for the hardware DPI values for the 3 modes and also the corresponding colors. the mask of enabled DPI modes, a DPI index (which the hardware does not seem to bound check at least not the way id expect). And the LED brightness for both software and hardware modes. I very interestingly did not find how the LED color itself is set or how the hardware mode animation is controlled. So there are unknown things left to be found. But for my purpose what i wanted (turing the LED off) i found all i wanted.
Code is here, pull request is also send, so it may or may not end in the official ckb-next

Since 15th march, everyone in austria can get 5 free rapid antigen selftests per month. When i first heared of the free self tests i thought, “i wish these where available half a year ago and shiped to everyone, one for every day, that would have safed lives”. One per week is better than nothing of course also now after the vaccines are increasingly available its a bit late.
I dont know if all austriawide are the same but the ones we got are simple lateral flow tests made by JOYSBIO (Tianjin) Biotechnology Co.,Ltd.
They came with 3 leaflets explaining not just how to do the test but also provide details about the tests performance.

Just today on youtube i again heard people talk about how crypto currencies are special as some are not inflationary while everything else fiat (printing), equity (dilution) and precious metals (mining) are inflationary. That is, all loose value over time.
But this is in some sense, not actually true.
Bitcoins require a blockchain to be maintained and the key requirement for that is that any adversary can never have 51% of the computational power. That requires a continuous “payment” of computational resources / energy. Which ultimately has the same effect as payment though someone printing/diluting/mining. If the blockchain is not maintained with enough computational power then at some point it becomes economic for an attacker to do double spend attacks by modifying the blockchain.
Iam sure iam not the first realizing this. But bitcoins kind of suck due to their vast computational blockchain maintaince requirements which also end up increasing co2 emissions or waste energy if it used renewables. Id wish we had some crypto that didnt had this energy problem and properly maintained privacy, it would be cool in a world where governments try to always increase their power over citizens and what they own.
PS: No, this is not supposed to be a prediction of what the bitcoin value will do in the coming years, it could go up alot or down by alot i have no clue.

Why would one want to do that? Because its a very simple project that doesnt really need a full configure script.
This is from the FFV1 build which builds the related RFC (draft) documents.

The tools versions are checked before a target that uses them, the tests are done just once and not again until you run make clean. It will put a file ending in version-ok for each tool in the build directory to keep track of what has been checked. These are cleared on a make clean.

Heres the full Makefile with the version checks showing how we ended up doing it. So far it seems working on everyones machiene who wanted to work on the ffv1 docs. Note, none of the authors of this Makefile is a Makefile expert, it certainly can be improved. I am just posting this as it might be a useful inspiration/ starting point to others who dont want a full configure in a small project.

PS: if someone has suggestions for improvements, pull requests are welcome in ffmpeg/ffv1

VERSION := 17
STATUS := draft-
OUTPUT := $(STATUS)ietf-cellar-ffv1-$(VERSION)

VERSION-v4 := 14
STATUS-v4 := draft-
OUTPUT-v4 := $(STATUS-v4)ietf-cellar-ffv1-v4-$(VERSION-v4)

$(info RFC rendering has been tested with mmark version 2.2.8, xml2rfc 2.32.0, xmlstarlet 1.6.1, pandoc 1.19.2.1, pdfcrop v1.38, and pdf2svg 0.2.3, please ensure these are installed and recent enough.)

all: $(OUTPUT).html $(OUTPUT).txt $(OUTPUT).xml $(OUTPUT-v4).html $(OUTPUT-v4).txt $(OUTPUT-v4).xml

$(OUTPUT).md: ffv1.md 
        cat rfc_frontmatter.md "$<" rfc_backmatter.md | grep -v "^AART:" | grep -v "^SVGC" | grep -v "{V4}" | sed "s|^AART:||g;s|{V3}||g;s|SVGI:||g;s|@BUILD_DATE@|$(shell date +'%F')|" > $(OUTPUT).md

$(OUTPUT-v4).md: ffv1.md 
        cat rfc_frontmatter.md "$<" rfc_backmatter.md | grep -v "^AART:" | grep -v "^SVGC" | grep -v "{V3}" | sed "s|^AART:||g;s|{V4}||g;s|SVGI:||g;s|@BUILD_DATE@|$(shell date +'%F')|" > $(OUTPUT-v4).md

%.xml: %.md mmark.version-ok xmlstarlet.version-ok pdfcrop.version-ok
        bash makesvg
        mmark "$<" | sed 's||undated|g' > "$@"
        xmlstarlet edit --inplace --insert "/rfc" --type attr -name sortRefs -v "true" "$@"
        bash svg2src "$@"

%.html: %.xml xml2rfc.version-ok
        xml2rfc --html --v3 "$<" -o "$@"

%.txt: %.xml xml2rfc.version-ok
        xml2rfc --v3 "$<" -o "$@"

clean:
        rm -f ffv1.pdf ffv1-v4.pdf ffv1.html ffv1-v4.html draft-ietf-cellar-ffv1-* merged_* mmark.version-ok xml2rfc.version-ok xmlstarlet.version-ok pdfcrop.version-ok

mmark.version-ok:
        test ` mmark --version | sed 's/\.\([0-9][0-9]\)/\1/g;s/\./0/g' `0 -ge 202080 && touch mmark.version-ok || (echo mmark version 2.2.8 or later is required && exit 1)

xml2rfc.version-ok:
        test ` xml2rfc --version | sed 's/.* //g;s/\.\([0-9][0-9]\)/\1/g;s/\./0/g' `0 -ge 232000 && touch xml2rfc.version-ok || (echo xml2rfc version 2.32.0 or later is required && exit 1)

xmlstarlet.version-ok:
        test ` xmlstarlet --version | head -1 | sed 's/\.\([0-9][0-9]\)/\1/g;s/\./0/g' `0 -ge 106010 && touch xmlstarlet.version-ok || (echo xmlstarlet version 1.6.1 or later is required && exit 1)

pdfcrop.version-ok:
        test ` pdfcrop --version | sed 's/.* v//;s/\.\([0-9][0-9]\)/\1/g;s/\./0/g' `0 -ge 1380 && touch pdfcrop.version-ok || (echo pdfcrop version 1.38 or later is required && exit 1)

A few days ago i wanted to print a page, nothing special here thats a common thing. But this time was different, my Samsung CLP-365 color laser printer did not print, its main LED red, the 4 toner leds all the same and lighting. On the linux side no error message or anything. Paper was in it, no paper stuck anywhere, power cycling did not help. None of the button combinations i could find that where intended to print debug information did print anything. Searching the wide net lead to a service manual and the tip to look at the display which my printer did not had and some windows software which required a windows machine. A youtube video pointed to the waste toner container but that was not the reason for the failure though it was messy.
What finally helped was connecting the printer to a mac, its printer drivers finally provided a useful error message, namely that the yellow toner cartridge was incompatible. It of course was not a original samsung one because the originals cost as much as a new printer. The other 3 cartridges where still the originals, the yellow one was bought from amazon a bit less than a year ago and it worked fine for a few months. (and this seemed not related to a firmware update)
The final confirmation that this was the issue came today as i received a replacement yellow toner cartridge again non original of course. And putting that in the printer, it came back to life, for now at least.
Iam not sure what i should think about this, but this is uncool. First samsung WTF, why if theres a fatal issue with a toner cartridge why do the LEDs for the toners all light up equally that gives 0 hope to one finding the issue. And iam not commenting about the whole toner original vs compatibility thing except id like the CEOs of all th e printer manufacteurs that make it hard to produce compatible toner cartridges to cleanup all the avoidable waste this creates. Go with a row boat please to the Great Pacific Garbage Patch and pick your incompatible toners and still good but misdiagnosed printers out and recycle them properly.

Thanks