warbiscuit

That's beautiful. Had no idea about that option.

I love PG, and don't plan to ever move away from it.

But I'm starting to wish they had in-place upgrades. Application I develop is getting to the point of "too large to make a copy of the whole db whenever I want to upgrade Postgres".

I can postpone things for a little while by replacing all our large objects with a external file storage -- but the tables themselves are growing quickly.

That'd be my favorite "big data" feature.

If I'm reading this right, the exploit is in the regex compilation stage, not the data matching stage; therefore remote exploitation would require the server setup to compile attacker-provided regexps, not just setup to run attacker data through an admin-configured regexp?

If that's the case, a typical nginx/apache config shouldn't be remotely vulnerable, right? Though I could see some shared hosting scenarios having some issues.

Not to mention: having all the data, and comprehending all the rows on an individual level, are two very different things. Doubly so if the data is irregular (I'm currently doing fuzzy matching on really mangled street address data. ICK).

Once you hit millions of rows, it's not humanly possible to survey the data. All you can do is make assertions about the data's structure / buckets it will fall into. You then try to disprove that assertion, or establish an error bounds on it. You will never see all the data, only the results of assumptions you've made about it.

[Namecoin](https://namecoin.info/) is exactly that - in particular it's .bit domain is an attempt to be a blockchain-based decentralized DNS registrar. I'm not sure of the exact state of Namecoin with respect to DANES or other domain<->certificate binding protocols, but it looks like a pretty good start on the job.

Was posting to suggest exactly that, it's also what Python calls it (https://docs.python.org/2/library/functools.html#functools.p...), and a "partially evaluted / filled out" function basically encapsulated the whole concept.

Among others, there's gitlab.com and bitbucket.com (and also mercurial, as an alternative to git itself -- though the two can push/pull between each other's repos with the right plugin).

Ah. That's a relief, I was a little worried. But that makes it strange that someone, knowing of this limitation, would choose to start with the xml dump format.

Hard to believe mysql doesn't include that data in one of it's dump formats.

Ooh, that looks interesting ... and not just for ROM feature. They've packed a TON of things into there. Even SCRAM support!

I'm really intrigued by one of the planned features... "Hash upgrades to higher cost settings without knowledge of passwords". I can think of a way to implement that alone, but to pack that all in with those other features will be really impressive. And would be a huge boon to systems w/ infrequently logging-in users.

Yep... that was roughly my starting approach. Current one I'm playing with uses multiple samples (chosen as a function of the initial hash and the previous samples), to ensure the attacker has to actually take the whole file... otherwise the attacker gets away w/ 10% of file & 100 hashes, they've got good odds that one of those hashes only needs the first bit of the file.

Still trying to play with it to see if I can make it harder to parallelize assuming attacker does get the file. But that gets into designing an entire password hash, not just a friendly wrapper, which is more than I'm prepare to chew on right now :)

It's not necessarily "slow is best", but rather minimizing the ratio between how fast your production server can calculate them multiple hashes while under load, vs how fast your attacker can crack them on dedicated hardware.

Which, for example, is why something based on SHA3 is bad, because your typical server is just going to be doing SHA3 hashes via CPU. Except SHA3 was chosen to be ASIC-friendly, so your attacker will be able to calculate SHA3 faster than you. As long as the attacker has no faster calculation method than the one you're using, the absolute speed doesn't matter. This is why scrypt, bcrypt (and to a lesser extent pbkdf2-hmac-sha256) are doing well, because running them on GPU or ASIC isn't meaningfully faster than the CPU implementation the defender is using.

All that's left at that point is making it as expensive as possible for them to parallelize their attack. Which is what scrypt and other things attempt to do -- require as many non-CPU resources (memory, hd space, etc) so that the attacker's parallelization cost is also maximized.

(Personally, I've been playing around with the idea of incorporating random accesses to a 2-tb file of random data, so that the attacker would have a HUGE amount of data to steal before my hashes would work. And they'd have to establish shared access to all the CPUs/etc they're attacking with)

I'd argue that definition is incorrect.

To be unique, all something needs is to have a collection of properties which (taken together) are possessed by no other instance within some larger population.

Even then, it's still quite possible to have multiple unique objects within a set.

This quality of "uniqueness" can then be ranked, based on how many of those unique properties (or subsets of them) are sufficient to still make the item unique.

E.g. blue sphere among blue cubes is less unique than a red sphere among blue cubes.

So yes, "more unique" is perfectly reasonable IMHO :P

Regarding Python C extension compatibility ...

A number of projects (e.g. this bcrypt package -- https://pypi.python.org/pypi/bcrypt) have switched from using CPython's API for C extensions, and switched to the cffi package (https://pypi.python.org/pypi/cffi), giving them what seems to be a much cleaner (and less CPython-specific) break between the C-level and the Python-level code.

I say "seems to be" because I'm not too familiar with the internals to know for sure :) What cffi did give them is that bcrypt (with it's C component) can be used by both CPython and PyPy -- even though PyPy doesn't support any of CPython's native C API.

Meaning that PyPy just has to support cffi, and is otherwise freed from any fixed C interface itself. I think the reason cffi gives it this freedom is that cffi provides Python-side metadata about the C datastructures being worked with through cffi, allowing the PyPy JIT to efficiently integrate that information into it's compilation process.

I think he meant github, and the various features it offers, such as issues, pull requests, and threaded discussions thereof.

I'm also not a fan of github's monoculture (or for that matter, of git's -- i rather like mercurial). I've only got one or two open-source projects out there, but I've encountered the "you are aware of github, right? why are you using <insert anything else>" mindset before.

Ideally, git or mercurial or some dvcs gains the ability to track messages and issue tracking within the repository allowing multiple frontends (such as github) to make use of a common backend model. But until then, while github is nice, I think it shouldn't be a necessary requirement for running a project, merely a sufficient one. Homogeny breeds fragility, and all.

Typed too hastily, meant "in-place upgrades".

Not to mention that Debian consistently supports "in-place" upgrades when moving between releases, minimizing admin time doing the upgrade, and actual server downtime. Whereas Ubuntu... I tried using it on a few servers, their complete lack of in-place support meant the servers had to be rebuilt from scratch on a near-yearly basis if we wanted the latest release. Just not feasible.

I've been using VirtuaWin (http://virtuawin.sourceforge.net/) for a number of years to get virtual desktops on windows. It's a little of a pain to get installed & configured exactly as I want it, but it (along with selected plugins) get awfully close to replicating the MATE / Gnome2 virtual desktop system.

I've had good experiences with name.com, price and service -wise ... the frontpage isn't as slick, but once logged in the UI is nicer. Have yet to see a registrar with an actual good interface though :|

The most common pepper algorithm I've seen is doing e.g. "bcrypt(hmac_sha512(password, pepper), salt)" instead of "bcrypt(password, salt)". This has a number of advantages over working the pepper into the hash itself:

1) this wrapper can be applied to any hash scheme, regardless of it's internal structure or options.

2) it doesn't expose the pepper within the hash string.

3) brute-forcing the hash w/o the pepper means you're searching for the 64-byte binary string returned by hmac_sha512. whereas (assuming all inputs are ASCII) "md5(salt+pepper+password)" can still be brute-forced, just treat the pepper as part of the password you're looking for.