Re: [Discuss] Dropping obsolete commands (Linux Pocket Guide)
On 11/11/2015 07:32 AM, Edward Ned Harvey (blu) wrote: >> From: Discuss [mailto:discuss-bounces+blu=nedharvey@blu.org] On >> Behalf Of Chuck Anderson >> >> According to Ted Ts'o (filesystem developer), it is NOT a recommended >> way to backup your filesystem: >> >> http://www.gossamer-threads.com/lists/linux/kernel/1197768 >> >> "It does read the mounted block device directly, and so it's certainly >> not a _recommended_ way to back up your ext4 filesystem. It should > > That's correct, but unfortunately, it doesn't leave you with anything else > you can use. The problem is that the live filesystem can have stuff changing > while the operation is in progress. Because you're not using a block-level > snapshot. So even if you use something like rsync or rsnapshot, the tool will > walk the live filesystem (on top of the filesystem layer, unlike dump which > operates below the filesystem layer, but that distinction is irrelevant) the > filesystem could be changing while in the middle of an rsync operation. Or > tar, or cpio, or whatever. Your database files are not safe with *any* of > these tools, because of no block-level snapshot. > > If you make a block level snapshot, for example with lvm, you could then > safely backup the snapshot block device, just as you could safely mount the > snapshot and run rsync. But god, lvm snapshot, what a nightmare. > > This is the reason ZFS was invented. Maybe btrfs will be good someday too > (maybe it already is). I would recommend against btrfs. This is the first filesystem I've used in two decades where a power failure caused corruption. Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Dropping obsolete commands (Linux Pocket Guide)
On 11/09/2015 05:19 PM, Daniel Barrett wrote: > > While writing the third edition of my book, "Linux Pocket Guide" > (O'Reilly), which focuses on Linux commands that are the most useful > to know, I am considering dropping some topics that were in the > previous edition. I welcome any opinions on whether the following > commands are still widely useful enough to keep in the book. > > 1. dump and restore > > I grew up with these commands, but personally haven't used them in > well over a decade. What do you think? Been using Linux for over a decade, and never even run across these (and they're not installed by default on Debian or Ubuntu). Looking them up, it seems like what I'd use rsync/rsnapshot for. Do you include those? > 2. finger and chfn > > Likewise. Does anybody make use of finger information anymore, whether > on a single host or multiple? No. > 3. telnet > > I'm planning to mention telnet only for its utility in hitting > arbitrary ports (telnet myhost 80), and to drop all discussion of > remote logins with telnet, since it's largely been replaced by > ssh. (And maybe have a footnote about kerberized telnet being OK for > logins.) Agree/disagree? Agree. I might mention that it was historically used for remote login and been obsoleted, but that's about it. > 4. dnsdomainname, nisdomainname, ypdomainname > > These are just links to /bin/hostname for convenience and I never run > them. Do you? No. > 5. write and talk > > More commands I grew up with, but I suspect these have been completely > obsoleted by instant messaging. (Though I always liked "banner wake up > | write joe". :-)) Any reason to keep them? > > 6. Usenet > > The 2nd edition still covered slrn, but personally haven't run a > newsreader in years. For 5 and 6, I'd be slightly inclined to keep them, despite obsolescence because they're still about things to explore/have some fun with. (I guess this applies to finger as well, except there's no content, unlike Usenet, which has, if anything, too much.) Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Cloud-backup solutions for Linux?
On 09/29/2015 10:28 AM, Edward Ned Harvey (blu) wrote: >> From: Bill Bogstad [mailto:bogs...@pobox.com] >> >> While some OSes/filesystems handle power interruption well at this >> point, it seems to me that there are lots of apps/servers which do not >> and which people still need to use. Particularly in a VM environment >> where you might be running legacy OS/app combinations because you >> can't replace them, it seems to me that suggesting this method as a >> generic way to backup VMs is not really appropriate. Sure we should >> all replace our old software systems with ones that use transactions >> to protect against this kind of failure, but I don't think we are >> there yet. > > I haven't seen an OS, Filesystem, or a daemon, it at least 15 years, that > couldn't gracefully survive a power interruption. Except ownCloud. ;-) Not a power failure, but twice in the last 6 months I had a random reboot that left me unable to mount my root btrfs partition until I booted into a live CD to run 'btrfs check'. I've been trying out using subvolumes instead of partitions, but next reinstall I'm going back to ext4. I suppose it's possible that it was the btrfs error that caused the random reboot, not the other way around, but that's hardly better. Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Reusing Passwords on Different Sites Should be OK
On 09/17/2015 03:58 PM, Edward Ned Harvey (blu) wrote: > The present standard practice is for clients/users to establish an HTTPS > connection and > then send username and password over the wire, where the server will encrypt > it using a > rate-limiting function such as pbkdf2, bcrypt, or scrypt, to protect it > against hackers > or bad employees who have access to the password file or database or > whatever. But wait! > We should assume, that hackers and bad employees who can access the password > file can > also access the encryption programs (drupal, wordpress, apache, etc that run > bcrypt etc) > and have access to the password in-memory before it's encrypted. > > Worse yet, even if the server is never breached and the employees are always > perfect, > users sacrifice their legal right to privacy by merely making it possible for > the > employees to see it. https://en.wikipedia.org/wiki/Third-party_doctrine This is such a bizarre interpretation of "Third-party". A password should be considered a secret between two parties: client and server. But again, conceded that this is a problem. > This is like a > person writing their password on a postcard and assuming the mail carriers > will never > bother to look at it. Why do we make a distinction between the employees > operating the > routers on the internet, and the employees operating the web servers at > google and > facebook and everywhere else? We know we should never login to an http:// > site because > the random unknown employees who operate internet routers could see the > credentials in >-flight. We've all been trained to only login on valid https:// sites, even >though > potentially thousands of random unknown employees might be at work on the > other end, > able to see the credentials in-flight. > > tl;dr > There is no good reason to do the encryption on the server. It should be ok > to reuse > passwords on different sites, as long as the passwords are never exposed to > the servers. > > I work at Concept Blossom, and we're promoting awareness about this issue. We > produce > https://cbcrypt.org MIT open-source crypto library to address this issue. > We're > resource constrained on development, so development is taking place, but > slower than > we wish. Please spread the word and raise awareness as you wish. Even if some > other > implementation eventually becomes dominant instead of CBCrypt, this is a big > important > issue that I don't want affecting my daughter when she grows up. I've skimmed the docs. My understanding is that you're implementing per-site, unsigned client certificates that can be deterministically derived so that a certificate store isn't needed. And the protocol would basically be: - Open SSL session - Share public key - Challenge/response - Server looks up user data associated with public key A few thoughts: 1) The advantage to deterministically deriving keys is that I can go to somebody else's computer and login. The disadvantage is that now I'm giving access to my key material to any corrupted terminal. Keyloggers would be catastrophic since you're reusing passwords and don't need some kind of additional secret data. 2) You'll need browser buy-in to make the exchange happen at all on normal websites. Doing this in javascript is feasible (see clipperz.is) but doesn't resolve any trust issues at all. (For APIs you could do this no problem.) And you need some way of guaranteeing to users that *this site* is using CBCrypt or similar, otherwise reusing the password for your CBCrypt gives any password sniffer on the other end the ability to generate your keypairs as long as they can guess your username at each site, which is a catastrophic failure. 3) If you were to implement this in a password manager that could interface with a browser as a SSM, that might be the cleanest way to transition from a predominantly password-based ecosystem to a keypair ecosystem. For sites that don't have CBCrypt, randomly generated passwords can still be used. For sites that do, derived public keys could be shared, and the challenge/response could take place in the password manager, so private key material never leaves. Ultimately, replacing the SSM with a USB HSM would be ideal. 4) Given that, what advantage is deterministic key derivation giving you that a secure private key store wouldn't? Then the keylogger attack would be ineffective without also compromising the security module. Anyway, it's cool to see work along these lines. Key-based authentication that's aiming to be usable by the general public would be great. I'm glad to see the community moving away from the "everybody should learn crypto" model. Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Reusing Passwords on Different Sites Should be OK
On 09/18/2015 10:27 AM, Rich Pieri wrote: > On 9/18/2015 10:10 AM, Chris Markiewicz wrote: >> This is such a bizarre interpretation of "Third-party". A password >> should be considered a secret between two parties: client and server. >> But again, conceded that this is a problem. > > It's not a bizarre interpretation. It's case law. If you store your mail > (for example) on my server then you have voluntarily given your > information to me. You have no reasonable expectation of privacy > regarding that information. A password is no different. > > If you think my privacy policy protects you then think again. It only > stipulates that I won't give (or sell) your information to /other/ third > parties. It offers you no protection within my organization. I think you misinterpreted. I didn't say that you and your organization don't have access to information I voluntarily provide you, but that considering the person or machine I directly give information to as a "third party" and therefore public enough for government search and seizure without a warrant is bizarre. I recognize that it's case law, hence why I conceded the problem. That is in no way an argument against bizarreness. I'm not sure why people think asserting facts not in dispute is ever a relevant response to aesthetic judgments. Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Boston Linux Meeting Wednesday, September 16, 2015 - Jeff Schiller and PGP/GnuPG Keysigning Party XV
On 09/10/2015 06:54 AM, Jerry Feldman wrote: > When: September 16, 2015 7PM (6:30PM for Q) > Topic: Jeff Schiller and PGP/GnuPG Keysigning Party XV > Moderator: Jeff Schiller > Location: MIT Building E-51, Room 335 Any chance the fingerprints on the website can be put in a monospaced font, to reduce visual clutter in the table? http://blu.org/keysignings/keypartyregister.php I suspect it will make the process of verifying fingerprints at the key signing a little easier, as well. Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] privacy with pgp keys
On 09/10/2015 12:52 PM, John Abreau wrote: > At a keysigning party, the process is to verify each participant's > identity, and verify that the key they claim ownership of is actually under > their control. Each participant verifies their key id and fingerprint, and > then all participants examine each others' photo ids, and afterward each > participant signs the keys they feel confident about and emails each signed > key to the corresponding person, encrypted so that only the owner of the > key can retrieve the signature. > > If a key has been stripped of all traces of the owner's identity, I don't > see how it would be possible to adequately verify trust of that key during > the keysigning party. Outside the technical issues of what a keysigning party entails, and the standard policy for signing (some people aren't as strict or don't place much weight on government-issued ID), there is simply the question of what signing a key means. A key signature is an assertion that the identifying information in a UID accurately describes a person proven to have access to the key. The idea is that a person who trusts me (for some definition of trust) and wants to communicate with a person whose UID was signed, can believe that the public keys associated with that UID will help them talk to that person. Without UIDs, a key signature is meaningless. Sure, you may be able to build a trust path, but without a UID, you know nothing about who signed a message, or to whom you're encrypting a message. The signature itself is proof that the person who holds the key signed the message. The problem described by Mayuresh seems to be: (1) assure users of the key they're communicating with you; (2) don't provide metadata to surveillance. The web of trust is fundamentally incompatible with (2). Key signing parties will not help you get there. You'll need to distribute knowledge of your keys in some other way. If you want to use PGP/GPG for difficult-to-surveil communication, I would read this: https://gist.github.com/grugq/03167bed45e774551155 Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] privacy with pgp keys
On 09/10/2015 04:23 PM, Mayuresh Rajwadkar wrote: > hi > > http://pgp.mit.edu/pks/lookup?search=b5d1f0f4=index > > That uploaded key as a MD5 and SHA224 of the ID aka email... > One can verify that the email and fingerprint I provide will match up to > those hashes.. > Its not entirely impossible... If I understand you properly, when somebody wants to communicate with you, you would tell them something like: > Take my name and email address, and run the following commands: > $ UID='NAME ' > $ echo -n $UID | md5sum > $ gpg --search-keys `echo -n $UID | sha224sum | sed -e 's/ .*//'` > > Check the MD5 sums are the same, and make a note of the UUID, so you > can use it whenever you want to encrypt something (or put it in your > enigmail rules) At that point, why not simply use something like minilock (https://minilock.io/), where you just publish a 46-character public key? > I do appreciate Derek's concern... > > In my example I have used a UUID, which is the ultimate but one can use a > FirstName/LastName > which can be a little bit liberal, than providing an email address, > embedding a thumb-print jpeg, or > a IRIS-scan jpeg, or providing some kind of DNA fingerprint/sequence would > be kind a overly liberal ☺ than > just an email address, which is also possible... if privacy is no > concern... This honestly just sounds ill suited to PGP. Given that PGP isn't very popular, and is already inconvenient to learn and use, I'm not sure that augmenting it with an extra layer of work for anybody wishing to communicate with you is really compelling. Avoiding spam seems like a losing proposition, no matter what. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] how much can i use a smartphone as a computer?
On 09/09/2015 12:25 PM, barry wrote: > i.e. manipulate text read (and maybe type with external (bluetooth?) > keyboard), cut and paste across apps, pdfs, manipulate files in > directory structure, write and execute programs in, say, python > (accessing some of the opsys capabilities?) lets say android, lets say > rather low end for now > > it's time for me to get new cellphone, thinking of graduating from > simple flipfone... > > thanks I wouldn't expect to be able to seriously use it as a general purpose computer, mainly because of battery life and screen size make heavy use and multi-tasking difficult. There are decent filesystem browsers, and you can do most of the things you mentioned in a pinch, but beyond copy-paste and quick annotations, I think you'll get frustrated. My personal list of reasons I would keep my smartphone over going back to something I only have to charge once a week: 1) Maps. Advance planning is now only for things that need itineraries. How to get somewhere you've never been can be figured out on the way there. (There are also bus maps which show live locations.) 2) Ebooks/Games/Podcasts/etc. A variety of ways to occupy yourself, if you're looking for them. 5) TextSecure. Probably the encrypted messaging app that is hardest to use wrong. You can use it to text, but if you're talking to someone with TextSecure (or Signal on iPhone), it'll use a forward-secret OTR-like ratchet. 4) The Internet with a usable interface. Actually don't use this a lot, but when you need to quickly look something up, it's so much better than old phones. 5) A bunch of little utilities for notes or syncing shopping lists with housemates, or splitting checks. A lot of banks have apps that will let you deposit checks by taking pictures of the front and back, now. 6) Quality cameras, unless you're *really* into photography. Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] how much can i use a smartphone as a computer?
On 09/09/2015 03:38 PM, Kent Borg wrote: > > P.S. I don't use my Android devices for banking or brokerage accounts. > These enormous, new OSs are too big a target, too scary. I'll stick with > my Linux notebook for that; I run far less "interesting" software there. > Also I don't use any password managers on my daily phone or tablet for > the same reason that I don't trust them, rather I have a very cheap > little brand-x Chinese Android phone dedicated to being a password safe, > with nearly no software is installed on it, and I never let it connect > to the internet nor to any cell systems--I don't need to trust it that > much if I keep it incommunicado. (More likely I will use my Linux > notebook to look up passwords. Good passphrases are hard to enter on a > little touch screen.) Regarding passwords: I maintain a device-specific password database for things I need on each Android device, and keep separate, device-specific accounts when there isn't a compelling reason to use the same account across devices. This is mostly to limit the damage if my phone is stolen *and* the password manager (I use KeePass variants) is somehow broken into. Malware apps aren't very high on my list of threats, and I firewall the password app itself. I suppose something could traverse the filesystem, look for password databases and exfiltrate them, but the number of cycles they'd have to burn to crack more than a few databases puts this in the realm of targeted attacks. Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] A laptop for Linux
On 06/23/2015 09:03 AM, Ted Roche wrote: On Mon, Jun 22, 2015 at 10:45 AM, Bill Ricker bill.n1...@gmail.com wrote: The enterprise T-series Lenovo had been fine, but I'm hearing the latest models that no longer have mice buttons aren't up to the old standard. The last of the old enterprise models are still in refurb channels. And the new-ish T450 and 550s are just arriving in the refurb channels. These have the new and improved buttons that replace the all-in-one trackpad that replaced the buttons we all loved. Can't speak to the T series. Last I had was a T61 that was pretty solid. I will note though that I've had problems with the X series. Nothing in the way of days spent dealing with driver issues and kernel recompiles but sleep/hibernation are finicky and sometimes require a hard reset, and my work X230 ate through 3 hard drives and 3 LCDs before they finally gave up fixing it and ordered me a new X250. This thing uses an onboard Intel GPU which is... delicate. Videos that ran fine on older machines are now flickery, and sometimes it craps out mid-repaint and all of your windows turn into flat gray blobs until you reboot. I've run a supported (either current or latest LTS) Ubuntu on all of my ThinkPads, so it's wasn't a distro switch that caused the issues. Frankly, I'm disinclined toward Lenovo entirely at this point, but if anybody knows how much cross-pollination happens between the X and T lines, that would probably be useful for making a decision on modern T machines. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] cell Network time no longer provided
On 03/16/2015 09:46 AM, Shirley Márquez Dúlcey wrote: CDMA networks (Verizon, Sprint, and their MVNOs) are unlikely to make that change because they MUST have accurate time sources available at every cell site. Correct operation of the network requires that the sites be synchronized within milliseconds, because CDMA does soft handoffs as you travel. The network can reassemble partial reception from more than one site to piece together your conversation, and that requires that the timing be accurate. It's done by having a GPS time reference at each site. Since accurate time must be available in any case, they might as well continue to provide it to customers. T-Mobile, the other major GSM network in the US, still provides network time. Can confirm that my phone updated to DST on Sprint's network. Chris ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Rekonq doesn't trust my Certificate Authority
On 03/12/2015 07:28 AM, Dan Ritter wrote: On Thu, Mar 12, 2015 at 12:00:59AM -0400, Bill Horne wrote: I've come across an odd problem with Rekonq, and I'm looking for help. I have a real SSL certificate for my website, billhorne.com. It shows, as is expected, a padlock icon when I go to https://billhorne.com/ . Except when I use Rekonq, and then the KDE browser gives me an untrusted error, saying that the root CA certificate is not trusted for this use. Google searches show that it's a known problem, but the only pages I found were of suggestions that there was a MITM attack in progress or warning against using a self-signed cert. I took a screen shot of the deails page: it's at https://billhorne.com/snapshot1.png . All suggestions are welcome, and thank you in advance. https://www.ssllabs.com/ssltest/analyze.html?d=billhorne.comlatest You probably have some certificate chain problems that Rekonq is sensitive to. Yes, specifically, Bill is sending a GeoTrust Global CA cert signed by a weak (1024-bit) EquiFax CA. He is also not sending the RapidSSL intermediate cert. So Rekonq could be upset at the broken chain or possibly the partial chain being untrustworthy. Replacing your chain with the RapidSSL SHA256 CA - G3 cert with fingerprint 0e34141846e7423d37f20dc0ab06c9bbd843dc24 should resolve this. (Can be found here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=contentactp=CROSSLINKid=SO26457) You support weak algorithms -- try: SSLCipherSuite ALL:!ADH:RC4:+HIGH:+MEDIUM:!LOW:!EXP:!AECDH SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2 SSLCompression off With RC4, you have some weakness, but without RC4, you'll lose a lot of older browsers. In a year or three you can probably drop that, too. If it's a personal website, I don't see much disadvantage to dropping these. If somebody complains they can't see it, maybe consider reenabling RC4, but if you don't need to worry about losing business from people running XP, there's no need to preemptively weaken. On sites where I'm interested in making sure friends and family can connect, this is my suite: EECDH:EDH:!MEDIUM:!LOW:!EXP:!DSS:!aNULL:!eNULL:!RC4:!3DES:!SEED:!MD5 Again, though, I'm interested in personal users who have almost certainly upgraded machines in the last 5 years, not corporate clients who may be running early-00's tech. And when you renew the cert, you should get SHA2 instead of SHA1. Bill's is SHA2. It's the chain that's not. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
