unqueued

I combine git-annex with the bup special remote[1], which lets me still externalize big files, while benefiting from block level deduplication. Or depending on your needs, you can just use a tool like bup[2] or borg directly. Bup actually uses the git pack file format and git metadata.

I actually wrote a script which I'm happy to share, that makes this much easier, and even lets you mount your bup repo over .git/annex/objects for direct access.

[1]: https://git-annex.branchable.com/walkthrough/using_bup/

[2]: https://github.com/bup/bup

I never use split-screen view for Markdown. Split-screen makes sense for something more abstract like latex or html. But I do not see the benefit for Markdown. I would much rather have 50% of my screen.

I was astonished when I noticed requests like this after I logged into a customer portal:

  curl 'https://hondalink.honda.com/api/VehicleFeatures/[VIN NUMBER]' -H 'hondaHeaderType.country_code: US' -H 'hondaHeaderType.language_code: en' -H 'Authorization: Basic [DIGEST]' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'Car-Type: HONDA' 

Not just are they using basic http auth, but it is silently ignored by the server. Try it yourself.

They clearly intended to impelement authentication on their API endpoints, but didn't finish it, becuase the client is sending an Authorization header. But I don't know if their servers are even configured to check them. And they should certainly use JWT instead of digest.

This is a really cool product! I'm so glad someone is finally trying to solve this problem.

Not having control of your secrets is a big problem. It is why I continue to use TOTP for some things.

Maybe lean into the practical problem this solves and how it empowers the user?

I am going to suggest this to people. But I feel like I'd have to explain to them what it does, and why it is cool. I remember a few years ago when Keybase took off a few years ago. I think Keybase did a pretty good job of presenting itself to it's audience.

I know plenty of people who understand what a Yubikey is, but might not understand what this app is.

Personally, I love that I could keep backups of my TOTP secret keys in encrypted qr codes on paper in a safe, if I wanted to.

I think it is deeper than just the technical part of it. I think people really like anchoring their accounts to something that they can "see".

It would be really easy to let you import and export your secrets to physical media. And there are some interesting options with chaining your secrets to other hardware tokens (that you are in control of).

Of course it gets very tricky when suggesting anything security related. I don't want to tell people that they shouldn't use hardware tokens. But I think that relying on hardware tokens can be really inaccessible, which can itself be make a system less secure.

Best of luck!

I added a PR to fix rsync, mosh, and some other tools, since they will be broken out of the box.

But it seems this project has fallen behind on PRs.

If you would like to have this fix, you can do this after cloning the repo:

  git clone https://github.com/mathiasbynens/dotfiles && cd dotfiles

  git fetch origin "+refs/pull/*/head:refs/remotes/origin/pr/*" && git cherry-pick origin/pr/963

I was amazed when I learned that most powerbanks do not function that way. Some of them will switch modes if you unplug them, but there is still an interruption.

I was able to find a device that actually functions as a USB UPS: https://www.amazon.com/gp/product/B07ZS3WYZY/

It is so nice to be able to unplug my Pi to move it, and have it stay on. I also use them for my usb powered wifi security cameras. So far they have not failed me.

No, with JWT parsing it doesn't even have to look anything up, cached or otherwise. The JWT itself contains the information directly.

I could have a server that doesn't have any access to the database at all, and it could still render content for the user.

And if the server is for something critical, like purchases, it can still use redis on each request to verify that a JWT is still valid.

> Even when storing the cookies in a database like Postgres, they are fast enough because it's obviously indexed, and it's probably cached in many usage patterns.

If you scale up high enough, it does matter.

But beyond that, it is also about decoupling the server serving the content and the user database.

To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables to see if a specific user for that specific session is authorized to access that content.

There are going to be many joins involved. Even with good caching, it will still be a more complex operation.

Even if not computationally complex, it will be logically complex.

But when using a JWT, my server actually does not need ANY db access. It merely needs to verify the cryptographic validity of the included JWT header, which uses no IO. After that, it can safely trust any user metadata included in the JWT.

So, if a user has paid for access to all premium content after 2018, you would just include a field for that in your JWT payload. Done.

It depends of course on how your business data models work of course. But you can often put enough information in your JWT to cut out a lot of account processing logic.

> JWT is solving a non-problem for most people.

I think people are cargo culting JWTs.

Well, with the hub cli, it is just using GitHub's public API. I don't think it is doing anything proprietary.

For GitHub, using the hub[1] client, you can simply do:

  hub create -p

That will create a new private repo, matching the name of your repository.

What I will often do if I want to instantly mirror something to github:

  hub create -p --remote-name=github

Which will create a new remote with that name. Otherwise origin will be used, which can conflict if you already have an origin remote.

It is also less typing.

[1]: https://github.com/github/hub

I think it is good that it is so flexible, because you never know what kind of data you may want represented on your filesystem. I would rather that there be as few restrictions as possible.

There are cases where you will encounter lots of nasty filenames, especially if you are handling user generated content, like scraping from YouTube or Instagram.

Oh cool! I use nasty-files as a submodule with some of my tests. I can't believe how long I went without without testing against the filename corner cases.

I've found so much software that doesn't properly handle nasty filenames, I think it should be tested for more.

This is called ANSI-C quoting[1], and I am surprised it is not more popular, because I think it provides a good compromise with readability and power.

I used it myself when I wrote a script that generates a self executing bash script to restore mtimes for directories[2]

[1]: https://www.gnu.org/software/bash/manual/bash.html#ANSI_002d...

[2]: https://github.com/unqueued/storetouch

I would try to use JavaScript tooling in JavaScript projects, especially if I share it with other developers.

I would love to see better handling of filename transformation, file watching, and parallelization.

A few times over the years I had given up and just used Make instead of Gulp or Grunt. Most recently, I wanted to watch if files had been deleted (if directory entries had been modified). It ended up being a few lines of Makefile.

And once you understand the syntax, it is expressive and simple, and way more portable. There was some good discussion awhile ago on this[1]:

[1]: https://news.ycombinator.com/item?id=7622296

> HTTPS, with its current UX, would be a net negative in this case.

I would just replace "HTTPS" with "SSH", and see if that statement is still reasonable.

Even though SSH is not perfect when you can't verify the initial connection to a host on a local network, using TELNET instead is not a solution.

I have yet to hear a reason why HTTP is better than self signed and pinned HTTPS; why possibly insecure is worse than insecure.

The only justifications I have heard are UX justifications, and those are really just a critique of the UX, not the protocol.

> Security is done by physical access. Anything else is just extra complexity and points of failure, and if an attacker can get physical access to the LAN cable, he can just as well walk to the machine directly and change the settings on the control panel.

That is an extremely fragile solution.

By default ethernet is very open. It is very easy to bridge it with other devices or routers to announce themselves and start routing. It happens all the time on what are supposed to be closed networks, I've seen it.

And many networks are semi-offline. You may need to have limited internet access. Or the network configuration may change in the future.

Thanks for sharing! I wish this functionality was better exposed, it is such a game changer. I need to clean up and publish some of my scripts. I like to use firejail, xpra, and I'm trying to improve btrfs ephemeral subvolumes for my sandboxes.

Users should not have to rely on the network being isolated for security.

Even when I have an offline network, I still use SSH whenever possible.

Yes, I don't benefit from initial verification, but I pin the certificate from then on.

I don't think that the current "all or nothing" paradigm that we use with SSL in browsers makes any sense.

I have been really disappointed over the last few years deploying network connected devices and trying to make their services available in a secure way.

It is not really possible for ipcams, routers, etc to offer services in HTTPS in a semi-online network. There should be a kind of 'encrypted but unverified' mode.

Even the worst failure mode is no worse than a plaintext connection.

I found the most reliable barcode scanner to be an old Symbol usb scanner.

I also found that I could scan barcodes off of a screen with a laser scanner if I put a translucent white plastic bag over the screen. Maybe someone with more knowledge about optics could give some insight into why that trick works. My understanding is that laser scanners should only be able to scan by reflection, and shouldn't work off of a screen at all.

> The UX problem with self-signed certs is that you start expecting to accept them, so when that site asks you again to accept it while you are browsing in a cafe on a public WiFi, your browser would need to know that now you are on untrusted network and that you should better watch out.

But again, should you watch out more than if you were using HTTP? Does your browser make you opt in to connecting to every HTTP site on an open wifi network? What about an HTTP captive portal on an open network?

I have not heard a good argument for the current behavior with self signed certificates that justifies the behavior of completely unencrypted connections.

The ideal behavior would be for your browser to make it clear that the connection safe from third party attacks, but that it can't verify the website. Perhaps leave the scary warnings for submitting something over an self signed or unencrypted connection.

The current implementation is idiosyncratic.

Out of the box, you will get a lot more resistance for using a self signed certificate than bare HTTP. At the very least, self signed certificates should be in the same security context as HTTP.

Our devices should opportunistically use encryption, even if validation is not available.

I had a client that wanted to use an Android tablet to monitor IP cameras on his local network, and it was virtually impossible to use the TLS on zeroconf .local domains.

The official solution is to rely on the underlying network for security. Even though the webservers on devices and our browsers have TLS support.

Why is it that Google and the tech giants would rather that you use highly insecure HTTP than a possibly insecure self signed certificate?

You use self signed certificates all the time with SSH. If you haven't seen an SSH key before, you don't fall back to telnet.

If you stop to think about it, is incredible how much effort they put into forcing you to use the latest browser, and not trust self signed certificates. It is far easier to root your device and patch your kernel than it is to use an older browser.

Yes, it is a highly effective but clumsy heuristic to detect abuse. But I am convinced that they may have other incentives as well.

I really disagree with this idea. It reminds me of how developers try to prevent you from pasting passwords into password fields.

The benefit of using TOTP at all far outweighs the insecurity of storing it on the same computer. And it is so low effort, I use it everywhere possible.

I have a simple script that takes a screenshot, uses zbarimg to extract the single line otpauth:// string, and appends it to my pass password database[1], which then hooks back into my browser. I somehow don't think I would bother with a hardware key for my BestBuy.com account.

Besides, my password db is itself is encrypted with GPG, and GPG can use a hardware token to be unlocked, thereby giving you more flexibility and transparency, while still benefiting from a token.

Developers can't know what configuration users have.

[1]: https://www.passwordstore.org/

As it becomes easier to emulate hardware tokens[1], Google may start limiting which ones it accepts. I believe they can use attestation keys to do that.

This is just a softer layer of security to slow down less sophisticated mass signup attempts.

Google may very well eventually phase out TOTP, under the justification that it is not as secure, but I would be shocked if they ever retire the highly insecure SMS verification.

Because it is easy to automate TOTP, and it is probably not effective at slowing down signup attempts.

The pattern that has worked out really well for me, is to just organize my data into specialized collections, and not worry too much about the underlying filesystem.

I can't believe how much trouble I went through trying to find the filesystem that could do everything.

I mostly use git-annex, and various tagging systems, or just git repos. Now my data is much more portable and flexible. None of these tools are perfect, but I'm using tools that are mostly good at the job.

Whatever problem you are trying to solve, you probably don't need to solve it for your entire filesystem.

If you ever want to bring your old PalmOS device online and can't find the rare wifi cards, is to just use PPP over Bluetooth. You can also do PPP over the hotsync cable of IR.

https://wiki.archlinux.org/title/User:Jeffmikels/Bluetooth_P...

Once I learned this, I just did all of my Hotsyncing over the network.

Git-Mediawiki is indeed really cool! I wouldn't say it is that much the same though, and in practice it can be kind of impractical.

It takes a really long time to do an initial clone (sometimes many hours), and because it is still driving git, if the clone fails, it fails. Even after the initial clone, fetches can take quite a long time and there are many bugs.

I use it myself for archiving mediawikis.

Encycla seems much more git-first, which is also awesome.

Push notifications are a replacement for RSS in the same way that cars are a replacement for public transit.

This is a nonsense comparison. RSS is about presentation, not about real time interaction. And it would not be hard to have RSS feeds support push notifications, or other modernization.

RSS is a universal and accessible way of presenting content, that is what is so inconvenient about it to publishers.

The business model of most platforms today has RSS as competition. It completely undermines analytics, and their ability to fine-tune presentation, for the benefit of the end-user.

So of course GM will say that their gas guzzlers make electric trains obsolete.

I believe that there was an agenda to kill RSS, very much like how the auto makers in the United States conspired to kill public transit.

I don't buy any of the arguments not to implement it. I don't think it is too expensive or confusing. I think it is too empowering to users and inconvenient to marketers.

Oh wow, this seems pretty similar to this thing I wrote: https://github.com/unqueued/git-cache-tag

Which saves all uncommitted changes to a tag.

I wrote it because I wanted to have a complete snapshot of a build context. Sometimes composer or npm can't be relied upon to reproduce dependencies in the state they used to be, or I just want a cache of artifacts. It has been pretty handy.