Hacker News: bwblabs

New comment by bwblabs in "London Gatwick has launched a robotic airport parking service"

bwblabs — Sun, 26 Jul 2026 20:28:52 +0000

This is the video of the 11+ year old system installed in Århus Denmark by Lödige Industries from Germany. Lödige Industries more recent solution is actually moving the whole pallet you park on, so you can also plug your car into it: https://youtu.be/-_ZxnDrfwGk?t=46

The system in London Gatwick UK is done by Stanley Robotics from France (which was acquired by HL Robotics from South Korea in 2024), but it could be similar.

New comment by bwblabs in "London Gatwick has launched a robotic airport parking service"

bwblabs — Sun, 26 Jul 2026 18:33:41 +0000

2015-06-10 indeed: https://youtu.be/H4jYDfOzrjY

New comment by bwblabs in "Developers don't understand CORS (2019)"

bwblabs — Sun, 21 Jun 2026 08:49:22 +0000

> Any decent webdev should not let GET/HEAD/OPTIONS modify state

> additionally PUT/DELETE should also be idempotent

Yes, but I think the majority of large web applications are not fully correct in terms of 'Safe and Idempotent Methods' (https://datatracker.ietf.org/doc/html/rfc9110#name-common-me...).

New comment by bwblabs in "Developers don't understand CORS (2019)"

bwblabs — Sun, 21 Jun 2026 08:33:23 +0000

Another quote from the article:

> Further, native apps can generate a unique self-signed certificate.

Just creating a certificate will not work, unless it's installed as root CA certificates in all browser trust-stores on the machine. And if the private key of the root CA is not secured correctly, one could MitM any websites. So at least you want it name constrained (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....), but at least in Chrome until 2023 (v112) that did not work on root CA's (https://alexsci.com/blog/name-non-constraint/), so you had to add an intermediate CA and add the constrain there. Of course, you should also just throw away the key of the root CA.

I will admit I once added basic constrains in some project with a local root CA (2020-2022), but 'incorrectly' to the root CA, and did not test it in all browsers.

New comment by bwblabs in "What came first: the CNAME or the A record?"

bwblabs — Mon, 19 Jan 2026 22:25:21 +0000

I'm not sure, but we're seeing this specifically with _dmarc CNAMEing to '.hosted.dmarc-report.com' together with a TXT record type, also see this discussion users asking for this at deSEC: https://talk.desec.io/t/cannot-create-cname-and-txt-record-f...

My main point was however that it's really not okay that CloudFlare allows setting up other record types (e.g. TXT, but basically any) next to a CNAME.

New comment by bwblabs in "What came first: the CNAME or the A record?"

bwblabs — Mon, 19 Jan 2026 22:00:21 +0000

I will hijack this post to point out CloudFlare really doesn't understand RFC1034, their DNS authoritative interface only blocks A and AAAA if there is a CNAME defined, e.g. see this:

  $ echo "A AAAA CAA CNAME DS HTTPS LOC MX NS TXT" | sed -r 's/ /\n/g' | sed -r 's/^/rfc1034.wlbd.nl /g' | xargs dig +norec +noall +question +answer +authority @coco.ns.cloudflare.com
  ;rfc1034.wlbd.nl.  IN A
  rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
  ;rfc1034.wlbd.nl.  IN AAAA
  rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
  ;rfc1034.wlbd.nl.  IN CAA
  rfc1034.wlbd.nl. 300 IN CAA 0 issue "really"
  ;rfc1034.wlbd.nl.  IN CNAME
  rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
  ;rfc1034.wlbd.nl.  IN DS
  rfc1034.wlbd.nl. 300 IN DS 0 13 2 21A21D53B97D44AD49676B9476F312BA3CEDB11DDC3EC8D9C7AC6BAC A84271AE
  ;rfc1034.wlbd.nl.  IN HTTPS
  rfc1034.wlbd.nl. 300 IN HTTPS 1 . alpn="h3"
  ;rfc1034.wlbd.nl.  IN LOC
  rfc1034.wlbd.nl. 300 IN LOC 0 0 0.000 N 0 0 0.000 E 0.00m 0.00m 0.00m 0.00m
  ;rfc1034.wlbd.nl.  IN MX
  rfc1034.wlbd.nl. 300 IN MX 0 .
  ;rfc1034.wlbd.nl.  IN NS
  rfc1034.wlbd.nl. 300 IN NS rfc1034.wlbd.nl.
  ;rfc1034.wlbd.nl.  IN TXT
  rfc1034.wlbd.nl. 300 IN TXT "Check my cool label serving TXT and a CNAME, in violation with RFC1034"

The result is DNS resolvers (including CloudFlare Public DNS) will have a cache dependent result if you query e.g. a TXT record (depending if it has the CNAME cached). At internet.nl (https://github.com/internetstandards/) we found out because some people claimed to have some TXT DMARC record, while also CNAMEing this record (which results in cache dependent results, and since internet.nl uses RFC 9156 QName Minimisation, if first resolves A, and therefor caches the CNAME and will never see the TXT). People configure things similar to https://mxtoolbox.com/dmarc/dmarc-setup-cname instructions (which I find in conflict with RFC1034).

New comment by bwblabs in "Fahrplan – 39C3"

bwblabs — Fri, 26 Dec 2025 10:58:47 +0000

Tickets are sold (to the first email that arrived at 10:25 CEST, and the second ticket of a friend who's also a speaker to the second mailer at 11:11 CEST).

New comment by bwblabs in "Fahrplan – 39C3"

bwblabs — Fri, 26 Dec 2025 07:55:07 +0000

I've one ticket for sale (€190-255), since I bought two tickets (one € 255 supporter for myself and € 190 for partner) but also got a speaker ticket (https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/...), since speaker announcement was after the first round of sales via vouchers.

So let me know if someone is interested in this ticket, see my GitHub for mail address. I know other speakers where even unaware of this (so I might know another ticket for sale).

New comment by bwblabs in "Async DNS"

bwblabs — Mon, 15 Dec 2025 23:04:56 +0000

There is this list of things tech people think they understand (DNS, javascript), and more common you can see this with everyday people, e.g. with stuff like elections: the basic concept is clear, understandable, but the devil/complexity is in the detail, how to handle certain exceptions. I was employed by the Election Management Body of The Netherlands for a few years, so I can only vouch for the complexity of that relatively simple election system, but I'm pretty sure it will hold for about every country ;)

New comment by bwblabs in "Async DNS"

bwblabs — Fri, 12 Dec 2025 20:50:32 +0000

It falls into the category that most people think they understand DNS, the same as JavaScript, or e.g. elections, but the devil is in the detail. And I can tell you, at least for DNS (and Dutch Elections), it's kind of tricky, see fun cases like https://github.com/internetstandards/Internet.nl/issues/1370 and I thought the same before I had my current job which involves quite some tricky DNS stuff (and regarding this we also sometimes encounter bugs in unbound https://github.com/internetstandards/Internet.nl/issues/1803 )

But maybe DNSSEC is the 'unnecessary complexity' for you (I think it's kind of fundamental to secure DNS). Also without DNSSEC they needed RFC's like https://datatracker.ietf.org/doc/html/rfc8020 to clarify fundamentals (same goes for https://datatracker.ietf.org/doc/html/rfc8482 to fix stuff).

New comment by bwblabs in "Meeting notes between Forgejo and the Dutch government via Git commits"

bwblabs — Sat, 15 Nov 2025 16:28:49 +0000

See https://news.ycombinator.com/item?id=45929247#45930310

New comment by bwblabs in "Meeting notes between Forgejo and the Dutch government via Git commits"

bwblabs — Sat, 15 Nov 2025 16:26:24 +0000

can't read your linked comment: [flagged]

New comment by bwblabs in "Meeting notes between Forgejo and the Dutch government via Git commits"

bwblabs — Fri, 14 Nov 2025 22:18:49 +0000

You can do that by self hosting the code.

My point was that you don't need to compete with paid features, just please give the developers money to develop the software further (and fix bugs/issues), so e.g. buy some 'enterprise license', even if you don't need it in terms of features.

New comment by bwblabs in "Meeting notes between Forgejo and the Dutch government via Git commits"

bwblabs — Fri, 14 Nov 2025 22:15:16 +0000

It really depends, e.g. take a look at PostgreSQL, which is licensed under the PostgreSQL License, which is similar to MIT.

IMHO a MIT license is better than AGPL with a Contributor License Agreement (CLA) like with Elastic.

Gitea is MIT, so free and open-source, permissive.

Also see https://news.ycombinator.com/item?id=45929247#45930949

New comment by bwblabs in "Meeting notes between Forgejo and the Dutch government via Git commits"

bwblabs — Fri, 14 Nov 2025 21:47:31 +0000

Not sure why you misquoted, I said "the main contributors stayed with Gitea", also see https://news.ycombinator.com/item?id=45929247#45931139

When deciding which software fork to pick, it is about the development power. Also note my point about security: https://news.ycombinator.com/item?id=45929247#45930310

New comment by bwblabs in "Meeting notes between Forgejo and the Dutch government via Git commits"

bwblabs — Fri, 14 Nov 2025 19:49:05 +0000

A lot of the government are using public free accounts that I'm aware of.

I'm a 5+ year government employee, I touched quite some governmental repositories but all are non-paid.

I'm also a fan of the government hosting the code in an EU jurisdiction, preferably our own Dutch jurisdiction, and even better, self host.

New comment by bwblabs in "Meeting notes between Forgejo and the Dutch government via Git commits"

bwblabs — Fri, 14 Nov 2025 19:43:21 +0000

Correct, also see the initial discussion about changing the license: https://codeberg.org/forgejo/governance/pulls/24#issuecommen...

The issue with deviating from the upstream license is that only the code author can upstream a patch, since GPLv3 cannot be changed by a non-author of the code to MIT. Resulting in less being patched upstream, and so more merge conflicts, the maintenance burden I was talking about.

New comment by bwblabs in "Meeting notes between Forgejo and the Dutch government via Git commits"

bwblabs — Fri, 14 Nov 2025 19:18:07 +0000

Not sure: the government could just buy Gitea Enterprise license right? And thereby not really run true 'open source' software, but it would support the main development behind Gitea.

New comment by bwblabs in "Meeting notes between Forgejo and the Dutch government via Git commits"

bwblabs — Fri, 14 Nov 2025 19:02:44 +0000

See https://news.ycombinator.com/item?id=45929247#45930310

Forgejo used to be a set of patches applied on Gitea, but they moved to a fork with cherry picking Gitea commits, this is more work. In my view they don't have the development to keep up with Gitea.

New comment by bwblabs in "Meeting notes between Forgejo and the Dutch government via Git commits"

bwblabs — Fri, 14 Nov 2025 18:44:21 +0000

I know the claims, but look at Gitea version v1.24.7 (with some security fixes), released on October 25th, which includes 'fix LFS auth bypass, fix symlink bypass' that was merged on October 20th (#35708). This was fixed in Forgejo on the 25th https://codeberg.org/forgejo/forgejo/commit/fa1a2ba669301238... and released on the 26th, although "Originally scheduled for 7 November, the release date of these patches was advanced because a vulnerability had been leaked publicly." (https://codeberg.org/forgejo/forgejo/src/branch/forgejo/rele...)

Security wise, Gitea was safer in this case.

Also note the SECURITY.md was deleted: https://codeberg.org/forgejo/forgejo/commit/277dd02e706b6e51..., there is a security https://forgejo.org/docs/next/contributor/discussions/#secur... but it's a bit harder to find.

The problem is, Forgejo changed the license (https://codeberg.org/forgejo/governance/pulls/24#issuecommen...) and ended up doing a hard fork (https://forgejo.org/2024-02-forking-forward/#consequences-of...) which creates quite some maintenance burden. There used to be a (weekly) gitea chery-pick (e.g. https://codeberg.org/forgejo/forgejo/pulls?state=closed&labe...) but the TODO section was getting ever larger, and it seems it stopped in July (week 26).

So they start missing stuff, e.g. features like https://codeberg.org/forgejo/forgejo/issues/9552