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).
I don't think they're advising anyone create both a CNAME and TXT at the same label - but it certainly looks like that from the weird screenshot at step 5 (which doesn't match the text).
I think it's mistakenly a mish-mash of two different guides, one for 'how to use a CNAME to point to a third party DMARC service entirely' and one for 'how to host the DMARC record yourself' (irrespective of where the RUA goes).
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.
Yes. This type of behavior was what I was referring to in an earlier comment mentioning flashbacks to seeing logs from named filled with "cannot have cname and other data", and slapping my forehead asking "who keeps doing this?", in the days when editing files by hand was the norm. And then, of course having repeats of this feeling as tools were built, automations became increasingly common, and large service providers "standardized" interfaces (ostensibly to ensure correctness) allowing or even encouraging creation of bad zone configurations.
The more things change, the more things stay the same. :-)
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).
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).
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 )
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 ;)
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.
> The ideologically forked Forgejo made some license changes
Lets be clear. These "some license changes" that you reference was Forgejo forked Gitea and replaced MIT license with GPLv3. Forgejo doesn't want to be contributing to receiving effort from contributors into a project that then gets re-used, re-branded, and exploited by a big corp. By making the project copyleft they ensured that the contributions stay Free. This was an ethical move.
Gitea on the other hand doesn't mind sucking up free-of-charge contributions and handing them to a company to build their walled garden around.
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.
> Forgejo is more busy managing ideals, than creating software.
But managing ideals is far more important than creating software. Software is just a tool. It's a mean to an end, it's not the end in itself.
If software improves humanity we should create it. If not, we shouldn't. We shouldn't create software just because. We can, but that's not ethical.
And regarding your comments that "the original contributors stayed with Gitea", as if that's a point in favor of Gitea: Well of course! If the original contributors wanted copyleft that's how they would've licensed it. To me that just reinforces that I don't want to contribute to their project.
The misquotation was an accident but the point is the same. If the set of people who wanted to contribute to Free software split with from those who wanted to work for companies for free, that's an improvement.
> Forgejo is more busy managing ideals, than creating software.
Can't say I agree with this point. Zig has been trying out Forgejo/Codeberg as an alternative to GitHub, and about two months into the experiment, almost all of our technical concerns with Forgejo (and Forgejo Actions) have been addressed, with the only straggler being a UI bug related to the Cancel button in the Actions infrastructure (which has a WIP PR open, and which also has a straightforward workaround).
I can't speak to the platforms themselves, but in regards to their CI systems, it looks to me like the Forgejo Actions runner sees more development than the Gitea act_runner. For example, Forgejo gained support for concurrency groups recently, which to my knowledge are still not supported in Gitea.
The Forgejo people say that it is Gitea who is compromising security [0]. Not involved either way, but I have seen enough rug pulls that I will prefer the product which does not have a commercial offering and financial incentives to sabotage it.
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...)
Re: delayed security fixes, if a vulnerability is not yet publicly known and there is no indication that it is actively abused it is common practice to schedule fixes and give advance notice of them to have administrators be prepared to update promptly. The fact that the vulnerability was leaked beforehand is unfortunate, but Forgejo handled it well with rescheduling their release in response.
Re: license change, hard forking, and new features: my understanding is that Gitea wasn't very open to contributions coming from Forgejo. The hard fork seems to be a consequence of that. Yes, there used to be weekly cherry picks, I assume they stopped exactly because Forgejo and Gitea diverged to much and they became too much of a maintenance burden. Yes, this means Gitea has gotten features that aren't present in Forgejo since then. But you miss the point of the hard fork if you count this as a negative: Forgejo is deliberately diverging from Gitea now. Cooperation didn't work out, so they are no longer a superset of Gitea, but an entirely separate project. And as such they don't have more maintenance burden than Gitea itself.
And Forgejo definitely does not lack development power as its own now-independent project. They have features themselves that Gitea doesn't have. One notable that comes to mind is storage quotas, but there are many more too.
> 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.
And from other comments:
> When deciding which software fork to pick, it is about the development power.
> In my view they don't have the development to keep up with Gitea.
How do you come to the conclusion that Gitea has more development power? Looking at the Insights / Activities overview of each repository there were slightly more authors with more contributions to Forgejo over the last month. Acknowledging that this fluctuates I'd estimate that both projects are similarly active.
Also, Forgejo is actually dogfooding its development, which is much more reassuring than what Gitea does IMO.
I responded to that comment, but it does not address why you think Forgejo is lacking development power. IMO it rather shows a lack of understanding on your part of what Forgejo is today. It no longer is a superset of Gitea since the hard fork, but its own independent project instead. And as such it has at least comparable activity to Gitea, which is reflected e.g. in the unique features that Forgejo has, but Gitea doesn't.
As I've mentioned elsewhere [0], sometimes there's just fake outrage trying to associate drama or a general feeling of disapproval with a particular project.
Thanks. I was wondering what is the status of it, given that Forgejo is being pushed more in the media lately. TBH, I haven't understood the controversy even after reading a couple of recaps. I remember it being about having "suddenly revealed" a couple of years ago that the guy on top is the owner of the trademark. Doesn't sound like a big deal to me, given that he actually was the main contributor and de-facto the leader of the project the whole time.
But then a couple of years have passed, and I started to hear about Forgejo more often only very recently, so I was wondering, if maybe the original project actually had some downfall and questionable technical decisions since. I still haven't switched, and was wondering if I should do so. As far, as I've heard it's still basically a matter of running the different docker container with the same volume, and it should work seamlessly. So what's about this "hard fork" you are mentioning? Did it actually break compatibility?
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.
> Forgejo is more busy managing ideals, than creating software.
How many Elastic Searches will it take for people to realize that this is mandatory. Linux would not be where it is today were it not for some ideals wrangling.
Based on those meeting notes, the conflict of interest that arises when attempting to add features that compete with paid ones is real. So its that ideology that it is actually needed for a Government user/contributor.
To this day anything of worth that's been added to Gitea is released under MIT. Their business model is: you pay us to develop the features we need, we release them for everybody, which is how their collaboration with Blender has been working thus far. If it's good enough for Blender, who decided to stay with Gitea, it's good enough for me.
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.
There's a batch of dialog that indicates an interest in 'digital sovereignty', so it sounds like they are less interested in being an explicit customer of a given company.
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 appears to me that the rationale was clearly stated in GP:
> resulting in missing upstream features and decreased security
I.e. it's a matter of technical superiority, which, to me, how the decisions should be made. Not by having friends in the community and all of us being Europeans and so on. (But, of course, I would be glad to hear more particular details/examples of Forgejo lagging behind.)
You should simply compare release notes over the same time period for both projects, what's been done and how much. There's lots of nonsense repeated on this site and others, just do the research yourself, it won't take long. They both have very predictable release schedules.
We've stuck with Gitea, after not being impressed by the extremely FUDish behavior of the main driver of the fork, and this has proven to be the right choice so far. In spite of what some people claim, all of the major contributors to Gitea have continued developing it, none of the "heavy hitters" have left. It shows.
The database can be downgraded anyway. I've been doing backwards migrations for each new version all the way back to 1.22 (which is the last Gitea version that is "side-gradable" to Forgejo).
i dont get this blindspot by lots of developers parroting this uber technocratic nonsense.
There's no such thing as some apolitical, objectively best approach to a technical problem. Instead of arguing about specific merits about specific issues people throw out this big wide handwave about how "idea X is simply technically the wrong choice", as if this is a legit position to have.
Take a philosophy course for god's sake before you engineer us all to death.
I used to self-host Gogs on an RPi half a decade ago. At least for the needs of 1-2 people, it was one of the best pieces of software I ever used. If someone needs to host their repos privately, Gogs is more than enough.
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.
Most American financial service companies don't use DNSSEC; most American companies don't use DNSSEC; most of the tech industry doesn't use DNSSEC. Just to note that not finding a DS on mastercard.com is unsurprising.
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:
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.
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.
