m_sahaf

Worthy of note the Calibre-Web[0] project, which builds atop Calibre library to provide powerful web interface. The project and its maintainer deserve some love and support.

[0] https://github.com/janeczku/calibre-web

Adding to Francis input, the release artifacts (not the .deb packages, which are signed with Matt's key) published on GitHub are authenticated with Sigstore tooling[0]. You can verify the artifacts and the .deb packages were not tampered to the byte! The builds are reproducible and verifiable. FUD doesn't have any room to loiter.

You can also build it from source using the `buildable` source archive artifact that includes all the deps so it can be built in air-gapped machine. Like its sibling artifacts, the source archive is signed, the signature is published, the signing certificate is available, and the checksum is published and also signed. What's so concerning?

[Disclaimer: Affiliated with Caddy]

[0] https://www.sigstore.dev/how-it-works

Bolt has an open source Go package that tries to do that: https://github.com/BoltApp/sleet

Well, effort for such undertaking has started by yours truly as a Caddy module/plugin. Here's my announcement blog post: https://www.caffeinatedwonders.com/2022/03/28/new-ssh-server....

It's not abandoned. I'm still trying to move the project forward. I've just been busy with life. I've moved the repo to an org and put a new name on it: https://github.com/kadeessh/kadeessh. Contributions and help are more than welcome. I'd love to evolve the project, but I need hands and feedback from users, which I haven't received much of.

You configure Caddy to disable certain challenge types[0], which in this is the HTTP challenge, like so:

    example.com {
     tls {
      issuer acme {
       disable_http_challenge
      }
     }
     file_server
    }

[0] https://caddyserver.com/docs/caddyfile/directives/tls#acme

You're right that a customer shouldn't care the staff are too busy or too ignorant. You're also right in how complaining online short-circuits all that to actually receive help. I continuously advocate for the presence of path to higher levels and short-circuits! But it isn't always "the employee of company X responded to me on HN because my post made an executive squirm!" Some people just care and willing to lend a hand in cases where they can help.

> Don't blame minimum wage earners

If that's directed at me, I am not blaming anyone. Chill. I'm saying it's a human thing.

As someone who worked as front-line support and turned into the authority who's asked to resolve complex cases, this is nonsense. They aren't playing Tetris ignoring the queue. It's more likely the front-line staff are overwhelmed and/or don't know how to cut through the corporate hoops/politics to find and deliver the fix, and/or too shy/embarrassed to admit ignorance and having to pass it to the higher-ups for someone who knows how to fix things. It's more likely going in circles because they want to resolve it within their levels without having to escalate it.

C is a huge disadvantage when it comes do security.

You can use Caddy to automatically fetch certs and keep them renewed without much hassle[0].

Disclaimer: I'm affiliated with Caddy

[0]: https://caddy.community/t/using-caddy-to-keep-certificates-r...

Caddy is capable of handling bidirectional gRPC streams! I have just tested it, and it works just fine. Caddy will immediately flush writes when upstream is `h2` or `h2c`[0] instead of having to wait until reading from socket is complete

I used this Caddyfile to proxy to the route_guide example (https://github.com/grpc/grpc-go/tree/master/examples/route_g...):

```

localhost {

    reverse_proxy  h2c://localhost:50051

}

```

It works like a charm.

[0] https://github.com/caddyserver/caddy/blob/e4ce40f8ff04240540...

That's right. Moreover, the activity no the repo has been a bit stagnant (no disrespect to the maintainers, they are likely busy with other projects or life). Other projects have opted to fork the repo, rewrite the module repo path, and maintain their fork (e.g. https://github.com/tailscale/ssh/, but I've seen many others too). I didn't want to maintain a fork, so a copy under internal/ in my own repo means it's firm-fork (between soft and hard) where I can confidently break its APIs I'm the only one depending on without worry. It will slowly morph to fit the needs of the project only.

The maintainers gliderlabs/ssh have plans for a new version with more ergonomic APIs but the work hasn't started yet. I didn't want to wait either.

The plans are there! I focused on implementing the absolute necessary parts of every layer before taking round-2 for the more in-depth implementation. I actually have both the linked thread and the article saved aside to study when I'm ready to implement certificate-based authentication. Knowing Gitea already has it implemented, I had plans to study their implementation to know what I'm venturing into. If anybody else is interested in picking it up, please feel free to tackle it! I'd love to see that PR.

I've created tracking issue: https://github.com/mohammed90/caddy-ssh/issues/10

To be fair, this bit is borrowed/forked from github.com/gliderlabs/ssh.

That's right! Currently such (static) keys are loaded at provision-time, when the server is first booting up, but there's nothing preventing it from being lazy-loaded at authentication-time. Of course loading them at authentication-time incurs latency as tax. Nothing prevents two separate modules from existing: one eager-loads the keys, and another lazy-loads them.

> - if your Goal was "secure by default", why did you allow passwords in the first place? Following Caddys recipe would be more like SSH-Keys only, wouldn't it? Is there a reason other than compatibility?

Compatibility was the consideration. The presence of the password based authentication does not mean it is enabled by default. In fact, if you don't enable any of the authentication flows and don't explicitly set `no_client_auth` to `true`, the server will not accept any request at all! You have to explicitly set `no_client_auth` to `true` for the server to allow unauthenticated users to login. The default is: none of the authentication methods are configured, and `no_client_auth` is false (meaning do not allow clients without authentication).

> - In that same avenue? Why allow such a thing as downloading authorized keys from a third party? Domain takeovers or account compromises on say Github are a thing - so again while it may be a nice usability aspect isn't that contrary to the secure by default pradigm?

That was just an example, but the implementation doesn't only support github. It supports any HTTP/S URL you provide. The point was that the source of the keys may even be an internal HTTPS service within your network that applies its own logic for keys issuance and generation.

Names are hard. I did consider changing the name but couldn't find another one. Feel free to pitch names on GitHub.

Caddy provides the module system and the config management backed by powerful REST API for config query and patching. If it wasn't for Caddy, I would've had to build all of that from scratch. That's too much to own.

Not very too level. I had to take that into consideration at some parts. For example, the static username_password provider calls a hasher defined in Caddy which uses `subtle.ConstantTimeCompare` function used. At other places, I don't return early (when possible) on auth failures to avoid timing attacks. That said, I'd love to know if there are places where I fell short.

Thank you! Indeed, you're right. The ultimate goal is to be drop-in replacement. There is a PR hanging waiting to be taken up. I might look at it once I finish furnishing the foundation, but others are welcome to take it up!

Hi everyone! Author here

This has been my stress-reliever for the past ~2 years. I'm sticking around, so feel free to ask any questions.

Github Repo: https://github.com/mohammed90/caddy-ssh

> abstracting information processing

Information processing is bookkeeping.

> Is math just bookkeeping? (of course not)

Why "of course not" though?

> Today the rqlite code deletes the SQLite database (if present) and then rebuilds it from the Raft log.

Neat! This is reminiscent of the replay of event log in Smalltalk.

Your Circuit Lab project was great and really helpful when I studied circuit analysis. That's the project I've known you for. Thank you for that!

The best option now is gio https://gioui.org/

There's also Bastille, which looks very interesting: https://bastillebsd.org/

Bitwarden's docs say it's possible to bring your own certs[0]. The Bitwarden marketplace image on DigitalOcean asks whether you want it to manage its own certs or not. From minor googling, it seems you can change your mind later by modifying a yaml file[1]. HN threading isn't best format for support. If this still doesn't help, let's move the discussion elsewhere.

[0] https://bitwarden.com/help/article/install-on-premise/

[1] https://gist.github.com/kylerchin/00e6990706183ddb0e0e792a1c...

Can you share what your setup is like? I have bitwarden_rs self-hosted with Caddy in the front doing TLS termination and proxying the request to Bitwarden_rs and haven't experienced any issues for more than a year and half now. There are many ways in how Caddy can be configured (e.g. maybe even just keeping the certs updated, but not serving any HTTP requests [0]). Feel free to drop a thread on the Caddy forum and we can help you out!

[0] https://caddy.community/t/using-caddy-to-keep-certificates-r...

If you're comfortable with the web stack and still want to stay lightweight, you can look into webview library[0]. I've used it with Go, and it also has bindings for other languages. It loads the platform's native browser with chroma-less window, just like an Electron app except perhaps lighter.

Another option is to look into Flutter. There are many available iterations for desktop applications, one of them is the go-flutter[1].

[0] https://github.com/webview

[1] https://github.com/go-flutter-desktop/go-flutter

SQLite recommends against sharing it on NFS for multiple access because locking is broken on NFS for all kinds of files, not just SQLite.

> But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time.

Source: https://www.sqlite.org/faq.html#q5

> Go is popular because of the names and organization behind it

I hear this a lot, but the counterexample is always Dart. Google is behind it, and Lars Bak is definitely not a nobody, yet the language struggled to gain momentum; not until Flutter came on the scene, and it wasn't an official Google project when it started.