From Callum Brown to ~sircmpwn/public-inbox
Hi Drew, Just want to say a quick thanks for todo.sr.ht. It's been very helpful organising my thoughts, planning what to tackle next, and keeping track of problems. And this is for a small project only I am working on! Highlights: - dense list lets me see lots of info at a glance and reduces scrolling and paging - tabular layout makes it easy to mentally sort and compare items - nice label system - "Submit another?"
From Callum Brown to ~sircmpwn/gmni-discuss
Hi, Solderpunk recently sent a "Request for feedback from server/client implementers using non-OpenSSL TLS stacks" to the Gemini mailing list. https://lists.orbitalfox.eu/archives/gemini/2021/007539.html gemini://rawtext.club/~sloum/geminilist/007539.gmi This might be of interest to people who use or develop gmni, and so I thought it worth linking here for those (like me) who do not subscribe to the gemini mailing list. Callum
From Callum Brown to ~sircmpwn/gmni-devel
With GCC 4.9.4 you get src/certs.c:75:2: error: missing braces around initializer [-Werror=missing-braces] br_skey_decoder_context skdec = {0}; --- Or you could have br_skey_decoder_context skdec = {{{0}}}; and use -Wno-missing-field-initializers Of course there probably aren't many people using error throwing versions any more. src/certs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/certs.c b/src/certs.c [message trimmed]
From Callum Brown to ~sircmpwn/gmni-discuss
I still haven't worked out what precisely is going wrong, but I have managed to reliably reproduce the issue by sending a ton of requests at once. Basically and extremely easy DoS attack. #!/bin/sh while true do gmni -j once gemini://xxxxx/ & done
From Callum Brown to ~sircmpwn/gmni-devel
Quoting RFC 5280 section 4.1.2.5 [0]:
> To indicate that a certificate has no well-defined expiration date,
> the notAfter SHOULD be assigned the GeneralizedTime value of
> 99991231235959Z.
This fixes commit 8b65e303b01fc573cb1c40a365fb5db166146a37 where the
certificate expiration is set to LONG_MAX seconds in the future.
Using LONG_MAX avoids an integer overflow when using 200 years on 32
bit systems, however on 64 bit systems LONG_MAX is 9223372036854775807,
which is around 292 billion years worth of seconds. Unsurpringly, this
doesn't go down well with X509 certificates.
[0] https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5
---
[message trimmed]
From Callum Brown to ~sircmpwn/gmni-discuss
Here it is: coredumpctl info shows the following stack trace: #0 0x00007ff231f86005 __GI__IO_fread (libc.so.6 + 0x86005) #1 0x0000561b774b1611 client_writable (gmnisrv + 0x11611) #2 0x0000561b774b1fcd server_run (gmnisrv + 0x11fcd) #3 0x0000561b774a6621 main (gmnisrv + 0x6621) #4 0x00007ff231f270b3 __libc_start_main (libc.so.6 + 0x270b3) #5 0x0000561b774a42ee _start (gmnisrv + 0x42ee)
From Callum Brown to ~sircmpwn/gmni-discuss
Ok. I've installed systemd-coredump and compiled gmnisrv with debugging symbols, so hopefully I'll get something useful next time it crashes :)
From Callum Brown to ~sircmpwn/gmni-discuss
Hi, I, along with some others, have noticed my gemini capsule going down regularly in the past two weeks. Unfortunately I don't yet have much information about what's going on, but, after being told (indirectly) that a couple other capsules have experienced what is likely the same problem, it seems like a good idea to post what I do know here. Since around 2021-03-26, my capsule gemini://calcuode.com/ has become unresponsive a couple of times per day, requiring the server to be restarted. At those times there are no errors shown, but looking through the logs I can see systemd has restarted gmnisrv (sometimes multiple times) after it failed due to a segmentation fault. I have not been able to reproduce this failure. I can also see some SSL errors in
From Callum Brown to ~adnano/gemini
On Wed, 10 Feb 2021 22:46:34 +0000, <me at nader.pm> wrote: > For example, if the proxy is at gemini://example.proxy, and the writer > wants to link to https://example.com, they can add a link to > gemini://example.proxy?https://example.com. When the proxy receives > such a request, it can pass the link to Mozilla's readability script > to clean it up, and then pipe the output through another script to > convert it to gemtext. A link to the original Web page can be added to > the top, in case the readability script couldn't do its job well > enough. The output will be served to the user, and it will be cached > for future requests (for one month, for example). This uses Mozilla's readability script, but doesn't deal with caching. https://git.sr.ht/~sircmpwn/cgi-scripts/tree/master/item/web.sh
From Callum Brown to ~callum/aura-web-client
On Tue Jan 26, 2021 at 8:10 PM GMT, R K Belew wrote: > hi Callum, > > First use of sr.ht, that's how interested i am in your aura work > connecting to beets! but can i really be the first to post > to your list?! in any case: Hello! Glad to hear you're interested in aura :-) Out of interest, how did you find the sr.ht experience? > i get a 'failed to fetch' exception, both when i use > `xdg-open index.html` or open the `index.html` directly > from a browser.