|
keyvin posted:You have a weird granny. yeah, who the gently caress wants to use mu4e when gnus works just fine and does usenet too
|
#
?
Nov 19, 2014 00:55
|
|
|
|
| # ? Jun 5, 2024 08:24 |
|
|
Kiwi Ghost Chips posted:too bad it still uses an obsolete file system at this point in time, all computers use obsolete filesystems by default
|
|
#
?
Nov 19, 2014 00:56
|
|
|
coreos has btrfs 
|
|
#
?
Nov 19, 2014 00:58
|
|
|
hooray! a half-baked filesystem.
|
|
#
?
Nov 19, 2014 01:01
|
|
|
pram posted:coreos has btrfs i don't understand the problems that btrfs is supposedly solving
|
|
#
?
Nov 19, 2014 01:05
|
|
|
then i invite you to read the wikipedia page about it
|
|
#
?
Nov 19, 2014 01:09
|
|
|
and then come back and tell us all why its superior tia
|
|
#
?
Nov 19, 2014 01:10
|
|
|
Mr Dog posted:i don't understand the problems that btrfs is supposedly solving problem: sun is putting ZFS all over their marketing materials solution: implement something vaguely similar in functionality but more complicated in internal design problem: btrfs is taking too long solution: buy sun
|
|
#
?
Nov 19, 2014 01:13
|
|
|
Mr Dog posted:i don't understand the problems that btrfs is supposedly solving the problem that btrfs solves is: * zfs isn't gpl
|
|
#
?
Nov 19, 2014 01:13
|
|
|
r u telling me we could have the worlds most advanced filesystem in the kernel if it wasnt for loving stallman
|
|
#
?
Nov 19, 2014 01:14
|
|
|
Soricidus posted:the problem that btrfs solves is: that's true, but ZFS also does useful things that weird beardo purists whine about being rampant layering violations and btrfs doesn't, which makes the beardos happy
|
|
#
?
Nov 19, 2014 01:17
|
|
|
pseudorandom name posted:rampant layering violations Is this a thing that makes the filesystem work good?
|
|
#
?
Nov 19, 2014 01:24
|
|
|
Captain Pike posted:Is this a thing that makes the filesystem work good? its actually a lazy mischaracterization of how ZFS works by beardos who didn't bother to understand it standard 1970s filesystems design has your block device which can randomly read or write fixed sized chunks and your filesystem built on top of that logical volume management complicates that up a bit by composing multiple block devices together in interesting ways, but the filesystems are still built entirely around randomly reading or writing fixed sized chunks (even if the LVM is secretly doing RAID or thin provisioning or spanning multiple devices or whatever behind your filesystems back) ZFS adds a bunch of useful verbs (like copy on write or explicit RAID-like IO behavior on individual chunks, etc.) to the standard block device paradigm, and then builds a filesystem on top of that that uses those verbs directly instead of limiting itself to randomly reading or writing fixed sized chunks. it also combined the LVM tools together with the filesystem tools because keeping them separate adds additional administrative complexity for no reason (particularly when your OS supports exactly one type of filesystem on your one type of LVM). beardos hate this. btrfs is actually built around a novel and interesting design (B+trees can't do COW because of the side links in the leaf nodes, Ohad Rodeh at IBM figured out how to do COW with B-trees), but it ends up being even more of a layer violation than ZFS and after seven years it is still immature both in performance and reliability
|
|
#
?
Nov 19, 2014 01:43
|
|
|
kill all beardos
|
|
#
?
Nov 19, 2014 01:47
|
|
|
Mr Dog posted:the problem with ssl is it tries to be all things to all people and generally has way too many knobs on it (much like your mother etc etc) Thats the whole point though is that SSL should be so piss-easy that you don't have to think about it at all. If everyone important got on the same page about this we could have the following worked out in like 2 weeks: 1) Apache/nginx/IIS all create self-signed certificates on the fly whenever a clear text communication would take place. 2) Web browsers accept self-signed certificates without making GBS threads themselves about how insecure everything is. It kills me that you get no warning from a modern browser for submitting data in cleartext but you get sirens and poo poo if you try to use a self-signed certificate.
|
|
#
?
Nov 19, 2014 01:52
|
|
|
Salt Fish posted:2) Web browsers accept self-signed certificates without making GBS threads themselves about how insecure everything is. you still need some semblance of this, like if you are at starbucks and convince somebody that you have a self-signed cert for citibank
|
|
#
?
Nov 19, 2014 01:56
|
|
|
That's because transmitting data with no security is a valid use case but there's never a reason to use a self-signed certificate because they're vulnerable to MITM. Somebody actually using a self-signed cert is a reasonable signal that you're the victim of an attack in progress. It'd be more useful if browsers complained at you before you submit credit card numbers or passwords in the clear.
|
|
#
?
Nov 19, 2014 01:57
|
|
|
lol self signed certs arent the answer. theyre already making a free CA anyway https://letsencrypt.org/
|
|
#
?
Nov 19, 2014 01:58
|
|
|
Cocoa Crispies posted:you still need some semblance of this, like if you are at starbucks and convince somebody that you have a self-signed cert for citibank We currently don't have warnings about cleartext connections so why do we need them for self-signed connections?
|
|
#
?
Nov 19, 2014 02:00
|
|
|
Salt Fish posted:We currently don't have warnings about cleartext connections so why do we need them for self-signed connections? because one of them is shown as implicitly 'secure' to the user
|
|
#
?
Nov 19, 2014 02:00
|
|
|
pseudorandom name posted:That's because transmitting data with no security is a valid use case but there's never a reason to use a self-signed certificate because they're vulnerable to MITM. Cleartext is objectively worse than self-signed. You can man in the middle even easier with cleartext. There is no reason to ever use cleartext.
|
|
#
?
Nov 19, 2014 02:01
|
|
|
Salt Fish posted:2) Web browsers accept self-signed certificates without making GBS threads themselves about how insecure everything is. in any situation that this is legitimately necessary for poo poo, and the (company in this example) is signing certs for internal use poo poo and needs to have browsers not "making GBS threads themselves" all they need to do is create a CA and sign the certs against it and push the root to your corp machines its not rocket science
|
|
#
?
Nov 19, 2014 02:01
|
|
|
pram posted:because one of them is shown as implicitly 'secure' to the user No, the presentation to the user is: self-signed <<<<<<<<< cleartext < signed Which is obviously wrong because its really: cleartext < self-signed < signed
|
|
#
?
Nov 19, 2014 02:02
|
|
|
Salt Fish posted:Cleartext is objectively worse than self-signed. You can man in the middle even easier with cleartext. There is no reason to ever use cleartext. Cleartext is known a priori to be insecure, self-signed is just as insecure but gives a completely false sense of security. The only way it'd be useful is if the browser UI just treated it as being cleartext, except the only time it shows up on the current Internet is when a MITM attack is in progress so browser UIs are even more hostile to the concept.
|
|
#
?
Nov 19, 2014 02:04
|
|
|
Salt Fish posted:No, the presentation to the user is: that's not true though. in 15 minutes i could have a server set up to respond as citibank.com with a cert that says i AM citibank.com self signed and (via dns hijack or whathaveyou) end up with your requests and you would want to know that the poo poo ain't actually vouched for by anyone. cleartext at least you're at the mercy of your own awareness and trusting that you are actually connected to the correct destination.. if you add a self signed cert behind that it makes the enduser aware that "wait something is fishy here" at the least...
|
|
#
?
Nov 19, 2014 02:05
|
|
|
pseudorandom name posted:Cleartext is known a priori to be insecure, self-signed is just as insecure but gives a completely false sense of security. No it isn't, you're making a strawman argument about some fictional "public at large" character that doesn't exist. You're assuming that there is no way imaginable that a browser could delineate between different levels of security for the end user. Your argument is clearly wrong because you're simultaneously assuming that the public at large knows that cleartext is insecure which I believe strongly is false.
|
|
#
?
Nov 19, 2014 02:06
|
|
|
they know. because secure sites have a green lockpad
|
|
#
?
Nov 19, 2014 02:07
|
|
|
pram posted:they know. because secure sites have a green lockpad Right. The browser is designed to seamlessly communicate to the end-user how secure the connection is. That is how it should be. Now go use chrome of FF or whatever and visit these 3 types of sites: 1) cleartext 2) self-signed 3) signed And you will be able to observe that the browser communicates to you that self-signed is less secure than cleartext which it isn't. If we could get rid of this problem of communicating to users we could configure web servers very easily to encrypt all internet traffic automatically. It would be a trivial detail compared to getting browsers to play along. Imagine this, red bar crossed out for cleartext, yellow bar with an open padlock for self-signed, green bar with locked padlock for signed. Now we upgrade our servers and all our pages go from red to yellow.
|
|
#
?
Nov 19, 2014 02:12
|
|
|
you seem really in love with your opinion so keep fuckin' that chicken i guess. but even your average grandma knows that, like pram said, "when i go to my bank it shows the padlock and turns green" means "im not going to get hacked" the simple truth is if you make it easy to make that padlock show up with a self signed cert/key pair then grandma would be fukken lost
|
|
#
?
Nov 19, 2014 02:12
|
|
|
secure sites have a padlock and maybe a green banner of some sort in the address bar. insecure sites don't. self-signed sites are insecure, so they won't get the padlock and definitely not the green banner. as far as the public is concerned, self-signed sites aren't secure. except: self-signed sites only show up in the wild when you are the victim of a MITM attack, so browsers correctly treat them even worse than standard insecure sites
|
|
#
?
Nov 19, 2014 02:12
|
|
|
The solution to the CA racket is DANE (EC or RSA public keys published in DNS and secured by DNSSEC), combined with a dead simple security protocol that uses said public key to perform a signed DH or ECDH negotiation and pick a symmetric ciphersuite for use with that DH-negotiated session key no X.509 monstrosity required and no compression bullshit or TCP-keepalive-reinventing bullshit to get owned by bam, done. For whatever reason though DANE isn't getting any traction
|
|
#
?
Nov 19, 2014 02:13
|
|
|
Salt Fish posted:Right. The browser is designed to seamlessly communicate to the end-user how secure the connection is. That is how it should be. Now go use chrome of FF or whatever and visit these 3 types of sites: self signed certs are not secure
|
|
#
?
Nov 19, 2014 02:14
|
|
|
Salt Fish posted:Right. The browser is designed to seamlessly communicate to the end-user how secure the connection is. That is how it should be. Now go use chrome of FF or whatever and visit these 3 types of sites: dude what the gently caress. most of the internet is clear text and doesnt need to be anything more secure. encryption exists to prevent people from reading the poo poo you send to a server and get back. i dont care about that when i'm streaming netflix that every video chunk is encrypted or when i browse a public forum that my posts are sent encrypted before they are displayed in clear text. scaring everyone with a giant red X when you're using normal rear end websites is retarded
|
|
#
?
Nov 19, 2014 02:14
|
|
|
The real solution is to disconnect from the internet.
|
|
#
?
Nov 19, 2014 02:15
|
|
|
Mr Dog posted:The solution to the CA racket is DANE (EC or RSA public keys published in DNS and secured by DNSSEC), combined with a dead simple security protocol that uses said public key to perform a signed DH or ECDH negotiation and pick a symmetric ciphersuite for use with that DH-negotiated bulk key pram posted:lol self signed certs arent the answer. theyre already making a free CA anyway
|
|
#
?
Nov 19, 2014 02:15
|
|
|
guys theyre making a free CA with a repo you can automatically install the certs with. u guys are complaining for nothing
|
|
#
?
Nov 19, 2014 02:16
|
|
|
pram posted:self signed certs are not secure They're more secure than cleartext. The only metric you could possibly use for declaring them 'not secure' is if your goal is perfect security which flatly does not exist. Sniep posted:dude what the gently caress. It does need to be more secure as it would raise the cost of bulk data collection to the point of making it impossible. It's 2014 there is no reason to use cleartext for any service. Salt Fish fucked around with this message at 02:18 on Nov 19, 2014 |
|
#
?
Nov 19, 2014 02:16
|
|
|
there is no CA to revoke them
|
|
#
?
Nov 19, 2014 02:17
|
|
|
u can spoof other domains
|
|
#
?
Nov 19, 2014 02:17
|
|
|
|
| # ? Jun 5, 2024 08:24 |
|
|
Salt Fish posted:They're more secure than cleartext. The only metric you could possibly use for declaring them 'not secure' is if your goal is perfect security which flatly does not exist. They are not. This is inarguable. Please stop posting and kill you are self.
|
|
#
?
Nov 19, 2014 02:18
|
|