taviso

Hey, another 1-2-3 nerd :)

I don't have any nostalgia it, I just appreciate how thoughtfully it was designed for data-input efficiency. I actually ported the official UNIX version of 1-2-3 to Linux a few years ago, I still use it regularly. It uses some tricks to get the original UNIX binaries working on Linux: https://github.com/taviso/123elf

I had been thinking about how to add UTF-8 support, it only supports LMBCS (Lotus Multi-Byte Character Set) by default. It's actually worse than that, it stores everything internally as LMBCS but in a lot of cases can only display ASCII, so it transliterates a lot of characters (e.g. é -> e).

It's also possible to run the real DOS version in dosemu - in terminal mode it's basically indistinguishable from an ncurses application, although dosemu is just cleverly sampling the framebuffer and translating it on-the-fly.

I wrote a display driver to make that work a little better: https://github.com/taviso/lotusdrv

Major breaking bugs.

A regression here and there would be normal before, major features breaking in this stable 25 year old software is simply unheard of.

This is not exciting cutting-edge software, it's a boring financial app. My instinct is people want stability and confidence that the output won't change and that their records will still parse.

I'm experiencing something similar with another piece of software. ledger-cli is a boring, dependable accounting application.

The next release will be the first where the majority of commits will be made by AI, and it has definitely not gone smoothly.

After a dozen or so bug reports, it's mostly in a working state, but I worry the output is no longer reliable in subtle ways.

If you hear a rumor that sounds too crazy to be true on social media, maybe don't repeat it as fact. Imagine how you would feel reading something like that.

why would you post such a patently absurd accusation.

I really liked the QNX Photon aesthetic, for a long time I maintained an absurdly complex FVWM configuration designed to look like it.

This was a screenshot of my Gentoo desktop around 2004!

https://lock.cmpxchg8b.com/img/fvwm_desktop.jpg

The point is to view it in a terminal (e.g. XTerm, Konsole, etc), of course you can just run it in an X server.

It's fun, but reminds me of a trick using Xvfb.

For example...

    $ Xvfb :7 &
    [1] 21688
    $ xeyes -display :7 &
    [2] 21697
    $ xwd -display :7 -name xeyes -out /dev/stdout | convert xwd:- sixel:-

Obviously no input though, you would have to use xdotool! The main benefit is that you probably already have all these tools installed :)

In 2022, Google TAG were awarded a "lamest vendor" award at defcon for fixing a Chrome vulnerability they discovered was being exploited in the wild... without asking for permission from the NSA first. That was the turning point for me.

I've used the tool sequin in the past to debug issues: https://github.com/charmbracelet/sequin

It worked great for me, seems much easier to debug logs directly in the terminal.

They accidentally used the example key from AES-CMAC RFC, the full details are in the accompanying blog post: https://bughunters.google.com/blog/5424842357473280/zen-and-...

The attacker doesn't need to literally be sitting at a keyboard, that can just be automated.

I'm curious though why you don't think TOTP or similar are good against credential stuffing though

I have written about this before, but looks like I lost the article somehow. https://web.archive.org/web/20210219185711/https://blog.cmpx...

Imagine you reuse the same password everywhere, and are sick of credential stuffing attacks. You ask your friend for advice, and your friend tells you to just enable TOTP when available, explaining that when there is a data breach you will be safe.

That is obviously bad advice, the vast majority of services do not use TOTP and you will have to race attackers to change your credentials quickly at dozens (hundreds?) of services. I think a reasonable person would say that you have not "prevented" credential stuffing.

A far better solution is unique passwords, it works today with all service providers.

I'm not familiar with the expert they consulted, but the claim that "The main advantage of 2FA is that it is much more difficult to gain access to your accounts via phishing attacks" is just plain false.

TOTP or SMS-2FA are obviously phishable, if you just entered your password into a phishing site, why wouldn't you also enter a TOTP code? I usually point to Modlishka as a practical example (https://vimeo.com/308709275) to help visualize this.

In fact, the main (claimed) advantage of 2FA is that it prevents "Credential Stuffing" of reused passwords. I personally don't think TOTP (or similar) are a good solution to this problem at all, but this is a thorny issue.

I think that's a miss for Claude, this doesn't look right at all. The accrual account is an okay solution, but the syntax is wrong! That syntax is only used for budgeting and forecasting.

I think the solution is effective dates, there is an example pretty close to this scenario in the manual:

https://ledger-cli.org/doc/ledger3.html#Effective-Dates

This seems like a weak excuse, the same problem exists on UNIX, but slocate solves it well enough. The slocate solution is to build the index and record permission and ownership, then it can restrict output to entries you have permission to see at query time.

I bought a few items at a drugstore yesterday, and noticed the cashier had very elaborate nails.

She used the second knuckles on her inverted hands (i.e. palm facing up) to operate the touchscreen PoS system, and was very efficient. Tool usage can sometimes be adapted.

I think they're talking about the cp example, doesn't seem like it would handle filenames with spaces!

Super neat project, btw!

Super cool, I didn't know about this - too bad it's not archived. I did know about a different game for 1-2-3, I even managed to track down original media and get it working in Linux!

https://lock.cmpxchg8b.com/doom.html

There is a brief gameplay video, if you want to see it.

I dunno, I think Debian are being wise here.

A while ago KeePassXC published a glowing audit report, but the report just ignored the scary stuff -- i.e. the things being disabled here like browser integration. I took a quick look, and thought the design could use some work -- but when I tried to discuss it they were very dismissive.

I did file a bug for one of the vulnerabilities we discussed, but I don't think they changed anything and didn't seem interested.

Testing cannot be used to prove that a flaw doesn't exist, only that it does.

FWIW, I wrote a similar blog post about a different encryption bug that really seemed like it should have been found by fuzzing, and had 100% coverage.

https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...

Not that I disagree with you, just a practical example.

I think I feel the same way, lag has never occurred to me when using xterm -- and I use the heavier features like translations and sixels day-to-day. Maybe it's just the Athena widget style that is making people dismiss it, because it's great.

The issue here is that the vendor did release patches, but then tried to hide that they fixed a vulnerability. This is usually called "silent patching", and it's controversial. As with any disclosure discussion, there are lots of opinions here and everyone likes to call everyone else irresponsible.

If you're pro-silent patching, you might argue that it reduces the number of people who know about a vulnerability, so publishing advisories is irresponsible.

If you're anti-silent patching, you might argue that it reveals the vulnerability to the people who monitor patches without giving any warning to the affected users that they need to patch, so not publishing advisories is irresponsible.

Maybe you're just a "minimum details" kind of person, and providing full details is irresponsible. Or maybe you're a "full details" kind of person, and restricting security professionals from accessing the information they need to do their jobs is irresponsible.

In summary, I'm irresponsible for leaving this comment and you're irresponsible for reading it.

Here are some examples!

https://github.com/taviso/ctypes.sh/blob/master/test/select.... https://github.com/taviso/ctypes.sh/blob/master/test/poll.sh

Yes, it is crazy :)

They should have used my (dumb?) library, ctypes.sh:

https://github.com/taviso/ctypes.sh

Then they can access libm, poll(), select() and so on from bash :)

The group selection the spammers target seems really strange, alt.comp.freeware is another example.

Not sure I understand what they're trying to achieve.

(I tried to raise the issue internally, fwiw).

I've been reading through vintage computer magazines in my spare time - this is from Unix Review, February 1986 issue. I was just struck with how this could almost be talking about GPT-4 or copilot, 40 years ago!

The technology must have seemed just around the corner...

Yes, exactly... :)

You can also create callbacks (i.e. function pointers to bash code) that you can pass to qsort() or bsearch()... or pthread_create? That last one was a joke, I mean, you probably could but I don't know what would happen - I don't think bash is reentrant :)

It's a funny trick, but you could probably also use setjmp and longjmp with ctypes.sh :-)

https://github.com/taviso/ctypes.sh

I'm not really sure, cpu and bandwidth utilization were fine. Memory usage was high, but not oom high. It continued serving over http just fine, perhaps there was some automated rate limiting by my provider.

I'll have to debug when things cool down.

I'm aware 128M is ludicrous in 2023... "a fun challenge", I thought to myself. I can be a dummy.

Yes. It was unexpected, but good. Not a complaint.