They/Them

Network Guardian Angel. Infosec.

Antispeciesist.

Anarchist.

Personal Website

You should hide scores on Lemmy. They are bad for you.

  • 14 Posts
  • 41 Comments
Joined duela urte bat
cake
Cake day: urt. 11, 2022

help-circle
rss


You can ask them in lemmy.ml/c/veganism We are open to people asking honest questions.


GnuPG signature spoofing via status line injection
How many nails does that coffin need?
fedilink

Yes, I knew about that and I find this an excellent feature! This is the reason why I’m asking about the “by default” behavior and not about “disabling score for everyone”. I like that this is optional. I’m asking the community their thoughts about having scores hidden by default ;)



Maybe they just like link aggregators and the classification by communities? I don’t use score-based sorting algorithms, precisely because I do not like how people vote on Lemmy.


I did not know that there are such options in Lemmy admin interface. That’s very good! Thank you for the information

Edit: According to the admin documentation, one can indeed disable downvotes but I don’t think one can hide scores for all users by default.

I checked and you are correct about beehaw. Thank you for the pointer. I’ll probably subscribe to their communities :)


Should scores be hidden by default?
Lemmy implements a scoring system allowing people to upvote or downvote posts. You know that since you are using Lemmy :) Score can be used to increase or lower visibility of posts, in particular when using some sorting algorithms (active, hot, top). This can be used to increase the visibility of good quality posts, and lower that of low quality or irrelevant posts. Yet, from what I observe, the tool is mostly used for communities to self-administer filter bubble. Some communities seem to behave like a hive mind, massively upvoting or downvoting until either the dissident is assimilated in a very Borg way, or excommunicated. Also, scores seem to be used often to convey cheap moral judgement, without having the need to expose oneself to criticism by providing arguments to sustain their opinion. Overall, I think scores are more toxic than useful, and I would be in favor of hiding them by default, so that new comers are not put out by them. What is your opinion about this? What are the advantages of having the score visible by default? Just a clarification: the question is not "should scores exist or not?". If people find value in scores, good for them. I'm not one to dictate other people preferences. :)
fedilink



(I would appreciate if the down voters were able to express their disagreement with words. Maybe I’m wrong, but then, please do me the favor of explaining me how. Also, I’m not a SourceHut hater; I even give money to Drew every month, because I like the idea of SourceHut. I just think Drew is wrong on that matter)



I don’t think that a robots.txt file is the appropriate tool here.

First off, robots.txt are just hints for respectful crawlers. Go proxies are not crawlers. They are just that: caching proxies for Go modules. If all Go developers were to use direct mode, I think the SourceHut traffic would be more, not less.

Second, let’s assume that Go devs would be willing to implement something to be mindful of robots.txt or retry-after indications. Would attackers do? Of course not.

If a legitimate although quite aggressive traffic is DDoSing SourceHut, that is primarily a SourceHut issue. Returning a 503 does not have to be respected by the client because the client has nothing to respect: the server just choose to say “I don’t want to answer that request. Good Bye”. This is certainly not a response that is costly to generate. Now, if the server tries to honor all requests and is poorly optimized, then the fault is on the server, not the client.

I have not read in details the Go Proxy implementation, to be truthful. I don’t know how it would react if SourceHut was answering 503 status code every now and then, when the fetching strategy is too aggressive. I would simply guess that the server would retry later and serve the Go developers a stale version of the module.


I don’t get it. Public endpoints are public. Go proxies (there are alternatives to direct mode or using Google proxy, such as Athens) are legitimate to query these public endpoints, as aggressively as they want. That’s not polite, but that’s how the open Internet works and always has.

I don’t get why SourceHut does not have any form of DDoS protection, or rate-limiting. I mean HTTP status 503 and the retry-after header are standard HTTP. That Drew chose a public outcry over implementing basic anti-applicative DDoS seems to be a very questionnable strategy. What would happen to the Sourcehut content if tomorrow attackers launch a DDoS attack on SourceHut? Will Drew post another public outcry on their blog?

SourceHut is still in alpha. This feels like a sign that it is still not mature enough to be a prod service for anyone.


The OpenPGP format was designed in the 90’ and never really changed since then. It was documented in RFC4880 in 2008. Unfortunately, in the 90’, people had really no good understanding of crypto yet, and the choices made were poor. Envelope design is poor. Some crypto algorithms are clearly outdated. Some default options are plain wrong.

Have you ever noticed that so many crypto attacks target OpenPGP and GnuPG? That’s not a surprise: it’s a popular crypto solution and it’s a relatively easy target, comparatively to some other mainstream crypto implementations. The Go langage maintainers even deprecated the OpenPGP implementation in their crypto standard library because they think OpenPGP is dangerous

OpenPGP is incompatible with https://golang.org/design/cryptography-principles, it’s complex, fragile, and unsafe, and using it exposes applications to a dangerous ecosystem.

Basically, I would say that the only thing that OpenPGP has for itself is the deployed infrastructure. Or has it? Web of trust is mostly dead, since keyservers are out-of-service. And OpenPGP adoption was never really that high to begin with.

SSH keys are much more widely deployed and used than OpenPGP keys. The format is dead simple, and the crypto implementation from OpenSSH is up-to-date.

I am very happy that git made SSH signing possible; it means I can delete my OpenPGP keys for good. I just hope linux distros will make the switch soon, to a more modern crypto approach: ssh signing or minisign.



Very good question. Thank you for asking.

To sign documents, I would recommend using signify or minisign.

To encrypt files, I guess one could use age

If you need a cryptolibrary, I would recommend nacl or sodium. In Go, I use nacl a lot. If you need to encrypt or sign very large files, I wrote a small library based on nacl.

Emails are the tricky part. It really depends on your workflow. When I was working for a gov infosec agency, we learned to never use any integrated email crypto solution. Save the blob, decrypt the blob in a secure environment. This helps significantly against leaks and against creating an oracle to the attacker’s benefit.

For data containers, I would use dm-crypt and dm-verity + a signed root. But that’s just me and I would probably not recommend this to other people :)

OpenPGP is rarely used in messaging protocols, but if it was I would probably advise leveraging a double ratchet library.


One example of issues with OpenPGP implementations that are a direct consequence of the poor format desgin… https://www.ssi.gouv.fr/uploads/2015/05/format-Oracles-on-OpenPGP.pdf


"sq feature comparison with gpg"
2022, people still use and make new implementations of OpenPGP. In 2015, I was already describing OpenPGP as a horror show for cryptographers. People need to move on! The format is wrong. The implementations are wrong. The mandatory ciphers are outdated. The web of trust is mostly dead since the key servers are broken.
fedilink

Does anyone know if and how the private key is secured during cloud sync? Do they have access to it or is it ciphered before sync using the… user password?

Also, how is it different from Duo Push? (edit: I am talking workflow, here. I know about the FIDO part)


I don’t think this argument is valid in a world where a global observer can already distinguish Tor traffic using timing and volume analysis.

Today, the best defense a VPN has to offer, privacy-wise, is protection against observers close to the victim, on hostile local network. Self-hosted VPNs can do that as well as any paying VPN service. The only reason I’m using a paying service myself is to circumvent geo restrictions. That’s basically the only valid use-case.


You can also hide votes altogether, which is a good thing. This limits expectations and helps fighting against addictive behaviors related to social rating.


"A new standard for signing, verifying and protecting software"
cross-posted from: https://lemmy.ml/post/256368 > (via https://infosec.exchange/@ScottMortimer/108243435027127879)
fedilink

I agree with all of your points :)


Can you elaborate on how this is FUD, please?

Introducing socialist millionaire verification to ease fingerprint verification does not seem a bad idea.

Using phone numbers as identifiers is a well-known Signal flaw.

And while CBC is indeed less robust that GCM regarding certain types of attacks, it is true that “up-to-date” CBC implementation have no known vulnerability. Yet, would you claim that TLS1.3 is FUDing for dropping CBC support as well?

I am not promoting mesibo, which I never heard about before. I am just trying to understand how this criticism of Signal would be invalid, or FUD.


A bit old, but an amazing read. Kudos to the author!
fedilink



Wow, perfect timing. I am currently struggling with efficient disk usage in my application. Thank you!




It doesn't work
An inspired blogpost by Frank Denis on the depression that may be felt by FOSS maintainers
fedilink

Secure large file decryption using Linux, Go and Nacl
In this article, I explain the challenges of decrypting large files that do not fit in RAM and some possible solutions leveraging Linux and a good high-level crypto library written in Go.
fedilink