rrobin

joined 2 years ago
MODERATOR OF
ccr
[–] rrobin@lemmy.world 3 points 1 day ago

It is a long article covering a bunch of things. But I'll try to cover the items in the comments.

GUIX puts things in different location, making it incompatible with fhs standard. This important for guix to be able to implement its core features, namely these TWO

  • guix can install/run multiple different versions of the same package (bash, firefox, whatever)
  • guix can run/rollback your system/packages to a previously known state by swapping a link (and loading some settings)

The problem for the "consumer" here happens when they try to drop a binary they download from the internet and it fails to run because:

  1. it will not run because it cannot find the link loader lib/ld-linux-x86-64.so.2
  2. it cannot find something else where it expects (/bin/bash, /usr/lib64/libgtk.so, etc)

The article covers two solutions for this problem: the first is patchelf (but is only meaningful for link loader and libs) and the second is to run inside a container (guix shell --container --emulate-fhs). I should note here the container solution is not that different from e.g. flatpak or similar.

Now for my personal (and very biased) opinion. I do like that guix enforces this and that random binaries from the internet don't simply run here.

Historically distros packaged software for various reasons - but one side effect of this is that package maintainers (i.e. your distro volunteers) vetted changes/updates, tested new releases and reported issues upstream (or patched it). For me this is an important part of Linux distros not being a monoculture.

Finally on a hopeful note. I don't think this is insurmountable. The article mentions two things that already exist 1) guix packages that wrap binaries in containers and 2) guix import that does auto imports for libraries. In principle there could be a tool that glues these two to automate it but this will probably happen in one of the projects that packages binaries (nonguix probably).

[–] rrobin@lemmy.world 21 points 2 months ago

Saving this. When we form the resistance against AI machines this will probably be the flag. Someone ship a few to Sarah Connor too.

[–] rrobin@lemmy.world 3 points 5 months ago

I know this issue has been brought up a few times

and I seem to recall someone using some mirrors in russia, but unfortunately I don't recall the details.

This issue has been mentioned in the mailing list back in 2019 and apparently there was this mirror in china

https://mail.gnu.org/archive/html/bug-guix/2022-05/msg00233.html

Since this has been mentioned before I think it is worth asking in IRC and the guix mailing list for an update.

If all that fails you could try bootstrap from source - but I don't know if source downloads are blocked too. And it would take a long time to build (assuming all goes well). This is done by passing --no-substitutes.

[–] rrobin@lemmy.world 1 points 5 months ago

This was once common, but it’s somewhat rare now in my experience, and the upcoming Matrix 2.0 apparently addresses most (all?) of the remaining causes.

I still see it - usual case is when someone has two clients. One of them will have issues with this.

I consider this a good thing, for the sake of the people who joined or wrote in the chat with the understanding that what they write is and will remain encrypted. If you want to abandon encryption, you can always create a new room.

Disabling encryption in the room did not have to mean decrypt past history. Yes you can create a new room. But for big groups who wants to risk it. The room admins I know steer clear of encrypted group chats because of the previous issue.

No, there is one officially released client for android: Element. Element X is in beta. When it leaves beta, it will take over as the one officially released client.

One would never guess based on the release announcement

This is just plain false.

https://spec.matrix.org/latest/client-server-api/#sending-encrypted-attachments

The docs say it clearly "If encryption is enabled". Otherwise attachments are just a link, nothing special there.

[–] rrobin@lemmy.world 4 points 5 months ago (3 children)

Yes and No

I consider matrix to be somewhat equivalent to XMPP or public mailing lists. It is potentially decentralized (even though everyone uses matrix.org) and it can host group chats. And for those purposes it is ok-ish, but for privacy it is no good.

My pet peeve with matrix is that I consider most features to be half baked. And instead of fixing them we just keep pilling up more. Here is a list in no particular order

  • encryption regularly breaks in weird ways, usually you see a message that you can't read
  • if you enable encryption in a chat room you cannot disable it
  • we now have two official clients for Android (Element and Element X) in the first one encryption breaks in weird ways, in the later there is no way to use Spaces properly
  • direct messages between people don't work well - it is like they are a room with the two people
  • privacy wise matrix is weak, leaks metadata, attachments are not encrypted, etc. Do not use if you expect privacy/anonymity. Also I think most groups run without encryption because of the other issues.
  • verifying sessions between clients is painful e.g. the client annoys me to verify but then verification does not trigger on the second client

Because of this mess your quality of experience will vary depending on the client and features you use. The web clients are usable.

I don't really use the video/audio calls so I have no comments on that front.

[–] rrobin@lemmy.world 2 points 6 months ago

Not sure which docs you are looking at, but my preferred description for this part is SMP

The previous message already pointed out the main point - communication happens via queues our clients knows to belong to the destination, and these queues are temporary. This means even if an attacker determines the queue belongs to a specific person it can be changed and even then it does not reveal who is the other contact using the queue.

A few more bits to consider:

  1. queues are unidirectional (so you need at least 2 for a contact) and you only create the ones you use to receive messages
  2. the server holds two identifiers for a queue - one for the sender one for the receiver
  3. the queue also has two keys - which allow the server to recognize the sender and receiver respectively i.e. only the sender can send and only the receiver can collect msgs (SMP server should reject otherwise)
  4. all the keys/ids i mentioned so far a created anew per queue
  5. finally the messages that are placed in the queue are encrypted between sender and receiver (DH) but is beyond SMP

So there are IDs but hopefully they are not useful for an attacker.

Now to answer your question. There are IDs but for a message to be delivered to the wrong person the following would need to happen

  1. you would have to send it to a server with the wrong ID and encrypted with wrong key
  2. the SMP server would need to allow this by decrypting it with the wrong key too (unlikely but not impossible I think - if we assume some magic to break point 3. from before)
  3. the message would then be picked up by the receiver (which would try to decrypt it but it would fail)

Caveats - the client app must be well implemented and NEVER reuse keys. Likewise the server must not reuse queue IDs.

I think I got my assumptions right. When in doubt check the 2nd link for a long step by step description of the protocol

[–] rrobin@lemmy.world 1 points 8 months ago

I think it is configured in guix-configuration from the guix service type

https://guix.gnu.org/manual/en/html_node/Base-Services.html

there is a tmpdir option there ("A directory path where the guix-daemon will perform builds").

I have not tried this, but something like this on your list of services

(service guix-service-type
  (guix-configuration
    (tmpdir "/whatever")))

As usual for any big changes it is best to try running the operating system spec in a vm with guix system vm to see if it boots up ok.

[–] rrobin@lemmy.world 3 points 9 months ago* (last edited 9 months ago)

Just pilling on some concrete examples, awesome-gemini is definitely the best place to start looking. There are both converters for the gemtext format and gateways for the protocols.

For format conversion tools, awesome-gemini already lists a handful of tools.

From the gemini side there are some gateways for specific websites operated by various people

  • BBC news gemini://freeshell.de/news/bbc.gmi
  • The Guardian gemini://guardian.shit.cx/world/
  • Lots of others gemini://gemi.dev/cgi-bin/waffle.cgi

These work pretty well for me. I think there were public gateways to open http pages from gemini, but I can't recall one from the top of my head.

Some of the gemini browsers support gemini proxies to access http(s) content. You can run it in your own machine. Duckling is the only one I'm familiar (but see the awesome list for more)

Conversely, to access gemini pages from a web browser portal.mozz.us hosts a gateway (just place whatever gemini link you want in the box).

One big privacy caveat of using gemini proxies for this is that while this may improve your privacy with regards to javascript/cookies it will reduced it because it makes your behaviour more identifiable from the point of view of the websites you visit (i.e. your proxy is clearly not a browser making it unusual).

[–] rrobin@lemmy.world 7 points 1 year ago

I can't offer a comparison with Session, since I'm not familiar w/ it. At a glance messages seem to be routed through some nodes that belong to a pool of service nodes that run some cryptocurrency stake (but I don't know what this means in practice). It does seem seem to do multi hop routing which means its more resilient to privacy attacks (but this says nothing about resiliency to being blocked).

On the SimpleX side, anyone can operate a SimpleX SMP server - that is the server that holds messages while in transit from the source to the destination (each server has a number of queues, each is one-way from a sender to a receiver ).

Each user defines the servers/queues he uses to receive messages, but not to send (those are the defined by the user you are sending messages to). So resilience to blocking means both users need to diversify the servers they use.

The folks running SimpleX host a handful of servers - and I expect those are the ones most people use. In that sense they are a point of failure for someone to block communication. If you check the source you will see an incomplete list of servers there, and in the app settings there are more (and you can add your own).

As for blocking the protocol, the following approaches seem standard for a state operator:

  • block TCP port 5223
  • if a different port is used, block based on TLS negotiation - this seems easy to spot
  • seize the public servers

(This is as far as my knowledge of SimpleX goes - the rest is slightly hand wavy assumptions I never checked)

I don't recall how the SimpleX app manages those server queue(s?). Taking a peek at the app right I only see one receive/send queue when I select a contact. But in theory it should be possible for it to have multiple queues per contact. The documentation does mention this in some comments (newQueueMsg: maybe it is not implemented?)

Finally the android app seems to support integration with ToR and will support .onion addresses if this is enabled, that is probably the most practical way to bypass some blocker (assuming ToR is not blocked :D). But this requires that the SMP server used by your contacts supports ToR addresses.

It would definitely be nice to see support for tunneling over other protocols, and of course more servers running those (ToR, I2P, gnunet?, etc, etc).

Some links to stuff:

[–] rrobin@lemmy.world 3 points 1 year ago (1 children)

Thanks for the list, there were a few I did not know about.

I would add ToR and GNUNet (https://www.gnunet.org/) too.

[–] rrobin@lemmy.world 9 points 1 year ago (1 children)

Depends on what you mean by "secure", being very loose with the definitions, we have

  • end to end confidentiality (i.e. only you and the intended destination can see the message contents)
  • privacy (only the destination knows i'm sending messages to them)
  • anonymity (no one can find out who you are, where you live, i.e. metadata/identity/etc)

My personal preference is Simplex.

Reasoning for a few:

  • Email: even if you use PGP to encrypt messages the server(s) in the delivery path have access to all metadata (sender, receiver, etc, etc). If no encryption is in use, they see everything. Encryption protocols in e-mail only protect the communication between client and server (or hop by hop for server to server)
  • XMPP: similar reasoning to email. i.e. the server knows what you send to who. I should note that XMPP has more options for confidentiality of message content (PGP, OMEMO, others). So I find it preferable to email - but architecturally not too different.
  • IRC: Again similar reasoning to email - even if your IRC server supports TLS, there is no end to end encryption to protect message contents. There were some solutions for message encryption/signing, but I've never seen them in the wild.
  • Signal: Good protocol (privacy, confidentiality, etc). Dependency on phone number is a privacy concern for me. I think there are 3rd party servers/apps without the use of phone numbers.
  • Simplex: Probably the strongest privacy protection you can find, but definitely not easy in terms of usability. The assumption is that we do not trust the intermediate server at all (and expose nothing to it), we just leave our encrypted messages there for the receiver to pick up later. It also does some funny stuff like padding messages with garbage.
  • Matrix: In theory it supports end to end encryption in various scenarios, but my experience with it has been so bad (UX, broken encrypted sessions) I only use it for public groups.

Some more food for though though; these protocols support both group communication and 1-1 messaging - privacy expectations for these two are very different. For example I don't care too much about confidentiality in a group chat if there are 3000 people in there. It might be more concerned with concealing my phone/name/metadata.

In general I consider large group chats "public", I can try to be anonymous, but have no other expectations. e.g. some people use some protocols over ToR because they do not trust the service (or even the destination) but they try to protect their anonymity.

On a technical note: I don't think there is any protocol that supports multi-device without some kind of vulnerability in the past. So I would temper my expectations if using these protocols across devices.

I'm not familiar with the other ones that were mentioned in comments or in the spreadsheet.

[–] rrobin@lemmy.world 4 points 1 year ago

There are gemini to http gateways so the content is probably already crawled anyway.

 

Less of a code review, more of a code trace on how Neovim plugin providers work. The content is my own.

Original source is hosted in gemini

 

A periodic thread to help find code reviewers.

Post requests for reviews here. Please include references to the specific version/patches/code you would like a review for.

 

Looks like gitlab now requires account verification for new accounts in addition to email. Either phone number or credit card.

This applies both to accounts created with a working email or by logging in using your github account. You can't even verify your email until you go through step 1.

I don't know when this started, but at least for the last month or two judging from these posts in the forums.

Fun fact: I don't even want to host on gitlab, I just wanted to report bugs in some projects. So I'm locked out.

view more: next ›