For those on one of the public servers (or any server with 'room isolation' enabled) only those in the same room can see any of this information, adding an additional layer of privacy. If a user don't want their viewing habits associated with them then they can just avoid using an identifiable username. As such, the only information transmitted is that someone going under a certain alias was playing a certain file or making a certain change to the playlist. Syncplay does not share your IP address with other users and does not require registration. Syncplay is not intended to be a secure chat facility, and indeed in the future we might allow for chat logging. In the message Syncplay displays at the top of the notification window it explicitly states: "Do not use Syncplay to send sensitive information". Syncplay is not intended to be used for sharing sensitive data. May I suggest YAML format? How do people feel about that? Let me alxpettit I can see the benefits, but there were a few reasons why I did not think we needed a TLS/SSL-only option: It might be about time to implement some sort of server config file, as an alternative to args (also helps for cases where the server has to run on an insecure system and the password is visible to anyone who can see the process running because it's passed as an arg). I'll go ahead and add that to the optdepends in the AUR package for Syncplay :)Įdit 2: also, it looks like we're now up to like 6 different options for servers. Staying within user expectations should help to reduce confusion and problems, if possible.Įdit: oh, I see it needs python-certifi now. All other server apps that make use of SSL that I've ever used ( nginx, apache, ngircd.) allow the user to separately designate the name and path of each file, which is less elegant, but provides more control.Īlso, rather than using chain.pem and cert.pem, they just use fullchain.pem. One thing I would change is to have separate arguments passing locations for the private key and cert chain, since the names of those files aren't very well standardized. I don't know if Syncplay clients keep working even if the server restarts in the middle of playing. On Mumble I have heard that there is git version reloading certificate on SIGUSR1 or SIGUSR2, I am not sure which and I have no idea if it has been released yet. On the other hand some versions of Mumble's server (murmur) only reload certificate on restart and there are unlucky cases where the server goes down for people, because automagic restarts it for renewing the certificate. While supporting TLS natively would be nice, I would wish my current setup to keep working, because otherwise I would need to bother a lot more with getting valid SSL certificates and how to automate LetsEncrypt certificate getting to Syncplay and reloading the certificate and all kinds of complications there may be.įor example ZNC currently reloads the certificate every time when a client is connecting, which is not very efficient. There are packages for Debian & RHEL based distributions, macOS and Windows, all instances get inter-Yggdrasil-IPv6 address that is based on their keys and within everything is end-to-end encrypted. This may be a bit offtopic, but I have encrypted connection to my Syncplay server with Yggdrasil network. we do not yet have something which is "Syncplay just works as you would expect, but it now has SSL support"). There is also the question of how to handle backwards compatibility, and whether if we are moving to SSL we should actually be moving to secure websockets to allow for browser-based implementations of Syncplay in the future.Īs per #107 (comment) and #107 (comment) has done some interesting initial work on 'endpoints' implementation that could theoretically move us closer to SSL, but in its current form it does not offer a continuity of experience (i.e. We do not want broken SSL support (or for SSL support to come at the expense of usability), so we would need someone with a good track record of SSL development to come up with an implementation which worked for Syncplay and to then not just implement it but also to maintain it. In the long term it seems like SSL (or equivalent) would be a nice feature to have, but none of the core Syncplay developers have sufficient SSL experience to really move this forwards.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |