bwblabs

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.

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

> 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...).

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.

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.

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).

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).

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).

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 ;)

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).

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

can't read your linked comment: [flagged]

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.

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

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

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.

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.

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.

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.

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

Very positive to have a governmental hosted git/code platform, although I would still advise Gitea (it's not documented that pick is explored).

I'm a self hosting GoGogs / Gitea user for almost 10 years, I did follow the Gitea fork. However regarding the Forgejo fork: the main contributors stayed with Gitea. The ideologically forked Forgejo made some license changes and hard fork decisions that increased the maintenance burden even more, resulting in missing upstream features and decreased security. Forgejo is more busy managing ideals, than creating software.

I recently found out https://github.com/ClementTsang/bottom#readme (cargo install bottom; executable btm), it's a pretty great improvement over htop I was using before.

Source: https://www.nrk.no/tromsogfinnmark/tromso-kommune-har-henvis...

Also listed in https://incidentdatabase.ai/cite/1009/

DNSSEC would have made the typo slightly less problematic. But [az.]mastercard.com does not do DNSSEC ...

See all issues on: https://internet.nl/site/mastercard.com/3122570

Nameserver is not reachable on advertised IPv6:

    $ dig +short +tcp @dns1.mastercard.com dns1.mastercard.com AAAA
    2607:3c00:6404:4::53

    $ dig +tcp @2607:3c00:6404:4::53 mastercard.com SOA
    ;; Connection to 2607:3c00:6404:4::53#53(2607:3c00:6404:4::53) for mastercard.com failed: timed out.

Also: no HSTS on apex, while HSTS with "includeSubDomains ; preload" on www, this does not work! And it's worse, they do some geo-redirect, so apperantly for US IP addresses http://www.mastercard.com redirects to https://www.mastercard.us/en-us.html (see https://hstspreload.org/api/v2/preloadable?domain=www.master...)

I also would expect an IPv6 on the apex/www, since there are quite some ISP's with IPv6 where IPv4 is a GCNAT, if there is a noisy user on the IPv4, it's tricky to block those, except if the ISP supports IPv6 and the web server too.

Weirdly enough the SOA serial which is in YYYYMMDDnn (see https://datatracker.ietf.org/doc/html/rfc1912#section-2.2) was not updated (still indicates 2011):

    $ dig +short +tcp @dns1.mastercard.com mastercard.com SOA
    dns1.mastercard.com. hostmaster.mastercard.com. 2011127982 14400 3600 2419200 300

Some other SOA record abnormalities:

    $ dig +short @a22-65.akam.net. az.mastercard.com SOA
    a1-29.akam.net. hostmaster.az.mastercard.com. 2020068768 3600 600 604800 300

Indicates 2020, and hostmaster@az.mastercard.com is not reachable because az.mastercard.com does not have an MX record, nor A/AAAA record.

Sadly nobody recorded this in either DNSViz history (https://dnsviz.net/d/az.mastercard.com/Z5ErUw/dnssec/ is the first) or ZoneMaster history (see https://www.zonemaster.net/en/result/3fa42e8e683db1bf).

In the provided CSV's by DigiCert there are 83_267 unique serials and 166_397 crt.sh links (137 have #N/A in the precert column***). Please note that crt.sh is Precertificates heavy for DigiCert (see https://crt.sh/cert-populations?group=RootOwner).

I did a lookup of all serials and based on 84 batch requests to crt.sh between 2024-07-31T20:06:00Z and 2024-07-31T21:06:00Z this was the result:

  Pre  Leaf  Count   Percentage
  -    0        137   0.16% ***
  0    1      2_105   2.53%  
  1    0     71_732  86.15%  
  1    1      9_293  11.16%  

These are the match numbers based on the serial and sha256 fingerprint combination. Only 13.69% of the Leaf certificates are found, while 97.31% of Precertificates are found. Because of these numbers, it's not strange that the 137 certificates without Precertificates cannot be found.

All 92_423 can be found in this bzip2 compressed attachment in tab-separated values format: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c16

These are certificates for 172_047 unique domains, of which 20_702 are wildcard and 71 IP Addresses (63 IPv4 and 8 IPv6).*

I just rechecked, and now everything works again from tree IPv6 networks I have access to.

Update: https://twitter.com/BWBroersma/status/1762566155691082135

At Internet.nl we're seeing IPv6 connection issues on TCP port 25 (SMTP) to mx[1-4].smtp.goog. Either 100% DROP (so no TCP connection) or ⅔ failure to setup connection. At least from AS20857, AS20860 and AS41887.

Can somebody ping Google/Gmail, it seems to be on their side.

Verify it yourself with: $ nc 2001:4860:4802:32::97 25

Replace 32 with 34, 36 or 38 for MX 2, 3 or 4, optionally use telnet / netcat / socat instead of nc. Please note in all cases ICMP (ping6 / traceroute6) does work.

Researcher of the leak. I got a question from NOS to test the security of a 6-length short code link (https://www.klm.nl/s/xxxxxx) used in text messages. I've tested two ranges (FAbxxx and KLmxxx), which gave a consistent 1% hit ratio of customer data (57% Air France, 43% KLM), NOS tested a smaller size random set (and got about 0.5%), 62^6*0.01=568 million. It was probably base64url (we now know - was also used, not yet got a _ confirmation).

Original posting of Dutch article: https://news.ycombinator.com/item?id=38681302

Researcher of the leak. I got a question from NOS to test the security of a 6-length short code link (https://www.klm.nl/s/xxxxxx) used in text messages. I've tested two ranges (FAbxxx and KLmxxx), which gave a consistent 1% hit ratio of customer data (57% Air France, 43% KLM), NOS tested a smaller size random set (and got about 0.5%), 62^6*0.01=568 million. It was probably base64url (we now know - was also used, not yet got a _ confirmation).

NLTimes link: https://news.ycombinator.com/item?id=38681707

It sounds 'late' to make it a docker container, but actually getting the IPv6 testing working with docker was challenging, only recently some IPv6 issues got solved, and the project needs the experimental and ip6tables docker flags to run.