Nemo157

But you are the second party, there is no third party involved when you use the software for yourself.

You don't need to pay to have an organization, I just created a personal organization to hold my non-experimental source repos.

Since unsoundness is a property of an interface, that private safe function would be unsound but could be used as part of the implementation details of a sound public API.

It's not something I would do personally, and would be something I'd put down as a black mark against using a library as a dependency, but it's nowhere near as bad as doing the same thing on a public API.

Then your code calling `pre_exec` is unsound, it is calling into `foo1` which is not documented to be async-signal-safe. Without any documentation saying otherwise you can't assume a function can be called within weird contexts with non-standard restrictions, and if they update to do something like add an allocation that causes your code to be UB, that's allowed by their documented API.

If you're improving the UI around here it would also be good to see how the list was determined. For automated detection in particular it seems like the tooling used also should be made public to allow testing. I know of at least one dependency that I would expect to turn up on sentry's list that doesn't. (A first guess: a bug in how you handle Rust workspaces, using the root to calculate dependency depth; alternatively a bug in your handling of non-lowercase github usernames, I notice there are only lowercase usernames in the list, but that might just be an artifact of your UI design).

The hash you have is computed from the hash of the content and other data. You would need to send that additional data out-of-band to allow the client to compute the overall hash and verify it. (Not to mention with urls like ipfs://<hash>/some/path you only have the hash of some arbitrary parent node, so there's even more additional data necessary to be able to verify that the content at that path under the hash you have is valid).

JS being required for the interactive features would be fine. My personal problem is that I end up on some random gitlab instance to just take a look at the source or issues for some library, and get a blank white page. For the read-only public view there should be no need for any JS.

Though IIRC from some bugginess I was noticing a while ago, only to the JS API, it will still obey the dark color scheme media query (but sometimes inconsistently, I would load the same page in multiple tabs and sometimes get dark or light schemes).

> In most cases, it just blocks or hides cookie related pop-ups.

This bit is actually the opposite. All tracking _must_ be opt-in, therefore by blocking the pop-up and not opting-in the website cannot track you.

It's only for the websites which are broken when not opting-in that it accepts the policy (which AIUI is itself a violation of the GDPR).

Just block them in your ad blocker, because they must be opt-in, by not interacting with them you are asserting your right to not be tracked.

A good one-time-sign-in-link implementation will send a link to authenticate a session elsewhere, so you can click the link on your phone to complete login on the computer.

IPv6 != static addresses. My IPv6 prefix changes at least once a day too.

It would if it worked, but every time I've tried using it I've hit some combination of crashes and weird false positives.