Postgres: The Bits You Haven't Found - <AUTHOR> http://postgres-bits.herokuapp.com/#1 <comment><USER2> The slides recommend UUIDs as a primary key ("just use UUIDs. seriously"). I took a look at the manual and there isn't too much of a Why (as well as 4 different versions of UUID to choose from). Anyone have a write up that explores UUIDs vs integer primary keys? I was only able to find people asking permission ("I have X with a UUID, can I use it as a pk?) rather than people talking about Why you would prefer UUID as the default.

Sidenote: Literally any button press you could reasonably expect to move to another slide works. PgDown, Right, Down, Space. Stop shitting up a decent submission to whine about it.

<comment><USER3> UUIDs are used as surrogate keys: <http://en.wikipedia.org/wiki/Surrogate_key>

<comment><USER4> Integer values are also used as surrogate values. Use of a natural key, IMO, is bad practice.

<comment><USER5> Why do you think natural key(s) (w/index(es) as needed) are bad practice? Data model refactoring?

<comment><USER4> A natural key as a primary key is terrible practice because I've never even once seen a natural key that wasn't tied to business logic. Logic that potentially can change.

Don't do it, you only make it worse for yourself if you pick a natural key for a PK!

</comment></comment></comment></comment></comment><comment><USER6> One note, Postgres is well over 18 years old. Postgres using SQL is 18 years old. Postgres had its own query language which was replaced with SQL in Postgres95, which in turn became PostgreSQL.

<comment><USER7> _PostgreSQL evolved from the Ingres project at the University of California, Berkeley. In 1982, the project leader, Michael Stonebraker, left Berkeley to make a proprietary version of Ingres. He returned to Berkeley in 1985 and started a post-Ingres project.

Starting in 1986, the team published a number of papers describing the basis of the system, and by 1988 had a prototype version. The team released version 1 to a small number of users in June 1989_

<http://en.wikipedia.org/wiki/PostgreSQL#History>

</comment></comment><comment><USER8> > caveat: WITH expressions are optimization boundaries

This is a pretty big caveat and one of the rare areas in which postgres does worse than other database systems. In SQL Server a non-recursive common table expression is treated by the optimizer similar to a macro - You can break up a complicated query with unions and group bys into easier to read cte:s and be confident that the optimizer will piece them all together into a query whose execution plan is equal to the original one.

But with postgres you can't because of the optimization boundaries. Its optimizer will attempt to make each cte as individually efficient as possible which can lead to a much worse execution plan overall. You can use views instead which, in contrast to cte:s, postgres optimizer can see through.

<comment><USER9> It's more subtle than "worse." Apparently CTE optimization fence is part of SQL standard, and it can be useful to hand-optimize queries.

But you are right, when using CTEs for readability it tends to hurt more than help.

Interesting thread about being able to control this: [http://www.postgresql.org/message- id/201209191305.44674.db@k...](http://www.postgresql.org/message- firstname.lastname@example.com)

<comment><USER8> Yeah, I've also heard that claim being made on the mailing list but it is probably wrong: [http://dba.stackexchange.com/questions/27425/is-the- optimisa...](http://dba.stackexchange.com/questions/27425/is-the-optimisation- fence-behaviour-of-a-cte-with-query-specified-in-the-sql2). For writable cte:s it matters, for read-only ones the number of execution times doesn't.

<comment><USER10> Sorta. It can be handy for guiding the optimizer away from a bad optimization choice but that's really a bad habit to get into.

</comment></comment></comment></comment><comment><USER10> Navigate with arrow keys - these are slides from a talk I gave.

<comment><USER11> I can't find the arrow keys on my phone :/

<comment><USER12> They are renamed "swipe" on mobile devices.

<comment><USER11> Definitely doesn't work on Android Chrome, at least.

<comment><USER13> Workng on 4.0.2 with Chrome for me. Landscape mode and then swipe.

</comment></comment></comment></comment></comment><comment><USER14> Interesting read! I assume, this is all not portable? Or is there similar functionality for other DB, say MySQL (not that I am aware of) or Oracle?

<comment><USER10> Some of it is in the standard, some of it is PG specific. MySQL is pretty terrible and doesn't support any of it that I'm aware of. I expect Oracle has their own versions of much of this stuff, but I've made it a hobby in my life to not learn Oracle.

<comment><USER15> Oracle has subquery factoring (the "with" clause) and recursion; native arrays, hash maps, collections, nested tables, and other complex data types; remote database links; queues (similar to listen/notify); regex querying; attribute-level timezone support; extremely powerful window functions; text search; tons of built-in crypto (if you really insist); and most of the related things on this list.

The biggest killers (vs. postgres): no simple helpers (generate_series, for example, is achievable with simple, efficient recursion, but you have to write the whole statement); a truly antiquated client program (sql _plus); built-in json, but you do have associative arrays/hash maps and nested tables, so you can achieve exactly the same thing, and it's_ indexable*; and range types (meh imo).

<comment><USER16> I think I've had Oracle blow up on multiple AS statements, so that's one place where Postgres would come out well in front.

Basically WITH-AS lets you declared temporary named subqueries. That is, a pretty stock standard programming technique -- give a name to a fiddly expression to simplify subsequent code. Very useful.

Oracle has lots of annoyances though. No SERIAL or IDENTITY type. Having to write the same boilerplate sequence/insert trigger/update trigger over and over and over is very tedious and a recipe for subtle errors when you forget one of them or mess it up.

No boolean type in SQL. I don't even know what to say about that.

<comment><USER17> "No boolean type in SQL. I don't even know what to say about that."

Tom ties himself into unbelievable knots trying to defend this. It's the purest form of technical Stockholm Syndrome I've ever seen from a putatively intelligent person.

</comment></comment></comment></comment></comment><comment><USER18> How do I move through the slides? Zooming out suggests there are more slides, but there's nothing to advance through them.

Chrome console:

Failed to load resource: the server responded with a status of 500 (Internal Server Error) <http://postgres-bits.herokuapp.com/js/sh_lang/sh_bash.min.js>

Uncaught HTTP error: status 500 sh_main.min.js:4

<comment><AUTHOR> You should be able to progress through the slides by using the arrow keys.

<comment><USER18> I admit that was a stupid thing to miss, it works fine, sorry. The Javascript error persists though, not sure if that's affecting anything, but there's nothing noticeable. Works fine for me on Android (default browser JB) too.

</comment></comment></comment><comment><USER19> In case someone is interested, I've created a ruby gem that uses hstore as backing store of multi-language text fields for Rails models. Contributions are welcome -> <https://github.com/firebaseco/multilang-hstore>

</comment><comment><USER20> The slides recommend using UUIDs (and not "numbers") as the primary key:

        CREATE TABLE t (
          uuid uuid PRIMARY KEY
                    DEFAULT uuid_generate_v4(),
          name text);

I understand that rows are stored physically in primary key order. Any idea if the "uuid-ossp" module, used to generate UUID primary keys, ensures that new rows are written sequentially on the disk after existing rows (which helps for both read- and write-locality)?

<comment><USER10> Postgres does not store keys in primary key order, actually, but in write order. This is an artifact of the MVCC model. There is a CLUSTER command that would do what you describe above, but it is (effectively) useless since you can't really run it without taking the database offline while the table gets rewritten.

<comment><USER21> You can do online clustering with pg_repack (<https://github.com/reorg/pg_repack>).

Given a table T, it will:

1\. Create a new empty table T'.

2\. Add a trigger on T that will clone any operations to T'.

3\. Copy all rows from T to T' in clustering order.

4\. Atomically switch the tables so that T' becomes T.

Unlike CLUSTER, the only lock required is in step 4, when it needs an exclusive lock on the table; it cannot do the switch until all current transactions are done with T (you can specify a timeout). The only other drawback is that that it does not support TRUNCATE, CREATE INDEX, or some ALTER TABLE operations being run while it's busy in step 3.

Also, unlike PostgreSQL's own CLUSTER command, it does not need an index to order by.

We run pg_repack regularly at night to keep our databases clustered. It works really well, though I really wish Postgres could get native online clustering. SQL Server has had automatic clustering for many years, as has DB2, and Oracle has index-ordered tables.

<comment><USER10> > though I really wish Postgres could get native online clustering.

Tell the community - pg_reorg could be cleaned up, improved, and merged into core... and should be!

<comment><USER22> I agree, although by native clustering I meant that the Postgres engine itself should support it, much like incremental vacuum was eventually built in.

pg_repack is a fork of pg_reorg (which has not been maintained since 2011), by the way, which has become the de facto replacement. No idea if the code is in need of cleanup or not, though.

</comment></comment></comment></comment></comment><comment><USER23> How were the slides generated? Looks pretty slick.

<comment><USER24> Note from someone who organizes conferences:

Do NOT use any slide deck framework that doesn't have a solid export function - jpgs, pdfs, whatever.

The videographer who will be editing your video will not be able to deal with your esoteric format - and screengrabbing every slide is horrible busy work.

<comment><AUTHOR> showoff can generate PDF's just fine

<comment><USER10> awesome, would you generate a PDF of my slides then?

</comment></comment></comment></comment><comment><USER25> Fantastic! I'm mostly a MySQL user, but the more I read about Postgres, the more I like.

<comment><USER26> I used to be really, really into MySQL, but since getting into Postgres I've come around to preferring it. They're both good.. but anecdotally Postgres is more developer friendly and generally easier to deal with in production. Postgres also comes with features that blow MySQL away in terms of flexibility and letting you do truly cool stuff. One example: Advanced query optimization with partial or reverse indexes.

<comment><USER27> One of the things I am missing in postgresql is compressed tables. It's actually big game changer in some cases.

</comment></comment></comment><comment><USER28> really really great stuff, thank you for posting. i had no idea about a lot of these. and you note that the source is still pretty clean after all these years.

</comment><comment><USER29> Can you re-order columns yet?

<http://wiki.postgresql.org/wiki/Alter_column_position>

18 years, and still, nobodys implemented this yet?

Its not a total deal breaker, but jeebus christopher columbus christ. It certainly would be nice.

<comment><USER30> Can you just specify the order in your query? Why do you care how the physical order is stored? Or do you even care about the physical order? Would an "apparent" logical order be sufficient?

<comment><USER29> If you're using postgresql strictly as a programming data store, its fine. Your app will certainly abstract away the ordering of the columns

Its just nice though, if you often find yourself working on raw tables using one of the many Admin tools. Sometimes you just need it to work like Excel to be productive. MySQL makes all of that trivial. PostgreSQL obviously keeps track of the order you created the columns, so being able to edit this ordering seems trivial in my mind.

It just seems odd that there certainly is _some_ demand there for it, yet nobodys picked up the slack in 18 years. Obviously there are workarounds. Why dont they include the work arounds as scripts with the distrobution, etc?

Maybe I will try to implement something and submit a patch. No experience in database dev though :(

Like I said though, its not a deal breaker. I'm just used to Open Source projects over-implementing features. Not under-implementing them. Especially after 18 years.

<comment><USER5>
      > Its just nice though, if you often find yourself working on raw tables using one of the many Admin tools. Sometimes you just need it to work like Excel to be productive.

Clearly this is a bug in the admin tool? I seem to recall MS SQL allows you to "drag columns around" -- obviously doing absolutely nothing to the database -- it's just a view. After all rows are just relational tuples -- they have no ordering.

<comment><USER29> True, a lot of the tooling for PostgreSQL is in its infancy when compared to something like MySQL. This problem definitely could be abstracted away by the tool. But because PostgreSQL doesnt support it natively, a side effect has been that many of the popular tools, comparable to ones in MySQL, dont have this feature either.

Anyone have any good suggestions for web frontend to PostgreSQL that supports reordering of columns as easily as MySQL? phpPgAdmin doesnt seem to compare to phpMyAdmin.

Admittedly I probably should be using a more robust OS native PostgreSQL admin tool, and not a web fronted. But alas, all of this is solved with MySQL quite nicely. I would like to see PostgreSQL catch up.

</comment></comment></comment></comment></comment><comment><USER31> Shame you can't view it on mobile (iPhone), saved for later.

</comment><comment><USER32> This was a really good presentation, I've worked with postgres and enterprisedb on and off for many years but I still managed to learn a few new things.

</comment><comment><USER14> Hm, how is that site supposed to work? Looks like there should be slide, but I can only see the title page.

</comment><comment><USER33> It looks like dozens, maybe hundreds, of people all had problem figuring out how to see the next slide.

Do the math, that's, cumulatively, probably an hour or two of life wasted perhaps more.

I expect webpages to have a mouse based interface, not a keyboard based interface and I'm not alone. It's not churlish of us to complain about our wasted time.

Interesting! And, as a postgresql lover, thanks for posting.

<comment><USER10> Glad you enjoyed the slides. I put a comment about navigation on the first slide. Hopefully that will help.

<comment><USER33> Me too!

I absolutely learned a ton from it ... I hope other Postgres fans didn't just walk away.

</comment></comment></comment><comment><USER34> awesome read, learned a lot.

</comment><comment><USER35> yet another example of "responsive interface" meaning "designed for a phone or a tablet"

<comment><USER36> I'm on my iPhone and its totally unviewable. It looks like I can see maybe 20% of a slide, with parts if that covered up by black bars. I can't resize or re- zoom.

Total disaster.

<comment><USER37> Calm down and view it via your browser on your PC.

</comment></comment></comment><comment><USER38> how about we just stop using keys that have no semantic meaning to their data, period?

<comment><USER39> Not sure if you're trolling, but just in case you're not: because any key that has semantic meaning to the data sooner or later is proven to be neither unique, always present nor constant.

<comment><USER17> If a selected key isn't unique, it's a failure of the data model.

<comment><USER16> It's a failure of clairvoyance, you mean.

Reality is more complex than any model.

That's _why_ we build models. They are, by their very nature, _simpler_ than reality.

<comment><USER17> Yeah, true. A model can be valid for some subset of data for some fixed period of time. The real failure is when the model isn't valid even for the defined period. Skill at articulating the limitations and implicit assumptions of any model is far too rare.

<comment><USER16> That's one thing I found really useful in reading Kimball's books -- the concept of fixed, slowly changing and quickly changing dimensions.

Everything is in flux, and you can choose to model that or not model it.

At the first level, you just model the current state of the system.

Then you begin to model the events that change the current state.

Then you begin to model changes in the shape of the problem domain.

Models all the way down ...</comment></comment></comment></comment></comment></comment>


I Dreamed of a Perfect Database - <AUTHOR> https://newrepublic.com/article/124425/dreamed-perfect-database <comment><USER2> I thought "relation" meant table, the author seems to use the word as if it means foreign key.</comment>


"Why are you releasing a full exploit just minutes after the patch is released?" - <AUTHOR> http://www.openwall.com/lists/oss-security/2015/07/23/17 <comment><USER2> I agree with Leif here. Sure releasing a PoC serves a purposes even in these cases, but this is just idiotic. One cannot expect outsiders to patch their systems this quickly. I would release without a PoC for a few weeks, maybe a month depending on how widespread the exploit is believed to be, to give everyone enough time to update. Humans need sleep , and some patches need downtime after all. Perhaps a tiered release would be best? Release a PoC to a few trusted partners to verify and pen-test the new patches before giving a full-disclosure. If there's something I'm missing here I'd love to hear it, cause frankly I feel like I'm just stating the obvious here...

<comment><USER3> > If there's something I'm missing here I'd love to hear it, cause frankly I > feel like I'm just stating the obvious here...

Likewise — I'm very much a n00b sysadmin, but I'm having a tough time understanding how giving people a buffer _isn 't_ desirable.

<comment><USER4> 1) It helps admins verify that the patch was successfully applied.

2) It gives security researchers more surface area to evaluate when looking for similar bugs or bugs in the patch.

3) A PoC not existing provides a false sense of security. Just because one is not published does not prevent attackers from creating and using an exploit (in many cases before the vulnerability is disclosed).

<comment><USER5> Again, delaying the PoC exploit code release gives people some time to patch their systems. How much time depends on the skill of the attacker and complexity of the exploit, but some time is better than no time.

<comment><USER6> And again the point of Titanous is that delaying the PoC provides a _false_ sense of security. Saying "some time is better than no time" _is_ the problem, you have a false impression that you _have_ time while the fact that the PoC is not published does not mean it is not already used by some attackers. Delaying does not provide an incentive to people to update. I agree that there is a tradeoff, but it is not a simple a you present it (delaying means giving some time).

<comment><USER7> It's not a matter or "impressions" but rather the matter of chance: when a vulnerability is published you may have the chance to fix it before someone figures how to use it in a exploit.

If the exploit is released immediately, that chance becomes effectively nil.

Of course this doesn't change the fact that everybody should apply the patch ASAP, but delaying the exploit simply adds some delay to the bad guys.

</comment></comment></comment></comment></comment></comment><comment><USER8> For those curious... click through the entire thread with thread-next>.

You'll be rewarded with some really great discussion!

</comment><comment><USER9> This is a local privilege escalation bug. If you're a SAAS company protecting user data and you were relying in some way on RCE not being a gameover flaw because it wouldn't give attackers root, you were probably already boned.

It's also a 90s style Unix file management bug. It's not like patches and vague advisories were going to keep the exploit under wraps.

That doesn't make it unreasonable to complain about exploits being released in advisories (though: this is a complaint that is approximately as old as security advisories), but it should dampen the outrage a bit.

</comment><comment><USER4> Working exploits are useful to test and iterate on to ensure that everything is patched correctly (both for admins and researchers).

/r/netsec has some good discussion: [https://www.reddit.com/r/netsec/comments/3ed4fu/cve20153245_...](https://www.reddit.com/r/netsec/comments/3ed4fu/cve20153245_and_cve20153245_local_exploit_that/)

<comment><USER5> They sure are valuable, he never said otherwise. His point was that the PoC exploit was released before or right at the time that patches became available and delaying the exploit PoC would give people a bit time to patch their systems.

<comment><USER10> Delaying PoC doesn't preclude others from analyzing the patch and writing exploits. The only thing delaying PoC does is provide a false sense of security.

<comment><USER11> I wish people would actually think about issues before saying "false sense of security." It's as useless as shouting "that's security through obscurity!" without thinking about things.

If you want to get rid of the False Sense Of Security, announce that there are working exploits out there.

<comment><USER10> The rationale for not releasing the PoC is that it gives legit users a chance to patch. This ignores the possibility of an attacker quickly developing an exploit as well as ignoring the scenario where bad actors already know and are exploiting the vulnerability. Not releasing PoC allows users think they have more time to patch than they actually do. This is a sense of security that is not actually derived from being secure in any way. What else should I call it?

This also prevents users from being able to test their machines vulnerability after patching to verify that the patch remedies the problem in their installation. Again, apply the patch, hope that it works in my installation (with my config options) is a piss poor security policy.

<comment><USER11> > Not releasing PoC allows users think they have more time to patch than they > actually do

This assumes a bunch of stuff about the psychology of everyone else that you cannot possibly know.

You are making decisions for other people because you think you know their business better than they actually do.

> This is a sense of security

You are not a telepath who can read people's minds.

</comment></comment></comment></comment></comment></comment><comment><USER12> That's what an embargo is and why it exists. And when it's up, it's up.

This is essentially a rehashing of the Microsoft/Google squabble a few months ago.

<comment><USER11> No, Google gave Microsoft X days to fix and release, and MS missed the deadline. (Assuming I'm thinking of the same issue as you.)

Google didn't release PoC exploit code the same instant as Microsoft released the fix.

</comment></comment><comment><USER13> Please pardon what may be a naive suggestion. This isn't my area and illness had me "benched" for a long while. Is there an inverted solution?

Maybe it's worth releasing not a simple PoC, but an unnecessarily large ball of executable or testing procedure that incorporates the PoC for testing purposes, but also does many harmless, exploit-like but nonsensical things, performing only one action that matters (the test.) A hairball of mostly trash code or procedure that is not trivial to untangle, in other words.

The idea is to create enough of a mess to stop the script kiddies from quickly knowing what to modify for their own purposes, not forever; but for a time.

Just maybe it would be possible to create a hairball that takes longer to untangle or trace than just having a pro tear apart the patch and roll their own attack, ignoring the hairball. If so, providing the test/PoC/hairball is not giving the pros in the black hats any extra time. (But in any case, at least you are not amusing all the script kiddies.)

If you can make a worthy hairball, you might just want to release the hairball just a little ahead of the patch; enough to whet admins' appetites for the patch - inverting the current order of release. (Or not.)

Again, this may not be practical in all cases or any; and my apologies if that's so.

PS There may be an argument in here for providing an "unnecessarily" and complex patch, too, to make it harder to reverse engineer - perhaps worth considering.

</comment><comment><USER14> They do it for personal marketing reasons. Someone else could have posted a PoC soon after and stole some of their spotlight.

I agree, it would be nice to wait a little while for people to get their patches installed. But also, people like to have a way to verify that the patch worked.

</comment><comment><USER15> Responsible disclosure is a courtesy, not an obligation, to criticize reeks of entitlement.

<comment><USER16> I strongly disagree, and don't follow this logic.

Responsible disclosure is intended to be ethical, the opposite is ... well, irresponsible.

I've worked with irresponsible security disclosurists before, and even those that agree to a window only to dump _another_ small variation after the window is up - rather than working to make sure the product is as good as it could be.

Giving end users time to patch so they are not owned is quite a ethical thing to do. The end goal is less compromised systems.

Doing this at the same time achieves the opposite effect and increases the amount of compromised systems.

It's never been "we're giving you two weeks, get it done fast because the exploit is going out then", it should be "we'll give you enough time to fix this properly, and then give the customers time to update once announced".

I personally would always release when something got done early, just because the person on the other end is usually unpredictable. However, the person on the other end shouldn't assume development of the fix didn't take the full interval.

Let people pen-test after they had a chance to update to secure the systems. Having the ability to prove a fix is not worth systems being owned prior to being able to fix them. The damage is already done at that point.

I've worked a lot of CVE reports, and about half the time, the person on the other end just wants credit, they aren't really going to hang around and try to help, and often they supply terse information (i.e. no exploit PoC to the vendor) as some form of game. I'd much rather this always be more user focused, the ultimate desire should always be to help the end user, and often users are less educated and don't have dedicated security teams.

<comment><USER9> "Responsible disclosure" is a term of art coined by a group of vendors and consultants with close ties to vendors. Baked into the term is the assumption that vendors have some kind of proprietary claim on research done by unrelated third parties --- that, having done work of their own volition and at their own expense, vuln researchers have an obligation to share it with vendors.

Many researchers _do_ share and coordinate, as a courtesy to the whole community. But the idea that they're obliged to is a little disquieting.

If vendors want to ensure that they get some control over the release schedules on their flaws, they can do what Google does and pay a shitload of money to build internal teams that can outcompete commercial research teams. Large companies that haven't come close to doing that shouldn't get to throw terms like "responsible disclosure" around too freely.

<comment><USER17> Although I take your point of principle, I'm not really sure I see any incentive to not share vulns. From what I can think, the options are:

1) Actively exploit - I think we can agree that providing it to someone who will actively exploit _is_ ethically dubious, or at least can be classified as irresponsible?

2) Share with the vendor. Ethically, this is fine.

3) Do nothing with it. Ethically, this is fine, although pointless.

4) If you make software that's supposed to detect and/or block the use of such vulnerabilities, add it to the detection system. I don't think this is a 'good guy' thing to do, although I suppose it could in principle be what's best for the company.

Having said that, my guess is that this last one has the smallest amount of commercial value, since it turns what might be a few months of work into a tiny part of a bigger piece of software; it's an investment that probably ranges (when overheads are considered) from $5-50k that has no value at all unless someone else finds the same bug.

But if someone else finds the bug, they could as easily be another security researcher as a bad guy, and then you've kinda lost out.

Have I missed anything here?

<comment><USER9> In this case we're not even talking about a vendor not getting access to a bug found by a third party (though that does happen). We're talking about a series of vendors notified ahead of time who now expect to have a say in how the researcher notifies others.

The general response a lot of vuln researchers have to this kind of sniping is that it should be directed to the person who wrote code after, say, 1995 that directly edited /etc/passwd instead of rebuilding and linking it.

</comment></comment></comment></comment></comment><comment><USER18> The actual answer is in the thread:

[http://www.openwall.com/lists/oss- security/2015/07/23/19](http://www.openwall.com/lists/oss- security/2015/07/23/19)

"That's how coordinated release dates work. Instead of trying to shame Qualys for not following your arbitrary views on what is and isn't "Responsible Disclosure", perhaps you should make sure Red Hat releases patches hours before the CRD, like Ubuntu does?"

The rest is the usual rehashed discussion on this topic.

<comment><USER11> > perhaps you should make sure Red Hat releases patches hours before the CRD, > like Ubuntu does?"

We could end up repasting the entire thread, but the very next comment is from Ubuntu denying that behavior. Releasing early is basically violating the embargo.

<comment><USER19> "There was absolutely nothing wrong with Qualys' timing. When the embargo ends, it ends." And then later some comments about people's panties being twisted, etc. which ends the thread.

Reading the entire thing is worthwhile.

</comment></comment></comment><comment><USER20> there's a lot of arguments here that delaying the patch release gives a false sense of security because we cannot prove that bad guys do not already have the exploit, or because they will develop one within hours.

if to have real security we must prove that bad guys do not have an exploit, would that not lead to a conclusion that there is no real security at all? it is safe to assume that exploits for undisclosed vulnerabilities exist. and, regarding the "several hours" argument, didn't the release of the exploit reduce those several hours to zero? instead of not being sure if the bad guys have the exploit, or if they will develop it in 1 or 3 hours, we are now certain that they have it. instead of a sense of false security, we currently have no security.

it seems obvious that little to nothing can be done about those who already have the exploit. and given the wide agreement that developing it will take a couple of hours, then wouldn't an optimal exploit release time be 1-2 hours?

and as far as i could notice, only one very downvoted comment mentions that a motivating factor for a quick release could be to be the first to break the news. certainly sounds like good PR for a security company. why is this unspeakable? :)

</comment><comment><USER21> For a particular system to actually be exploited, you need someone who (1) knows an exploit, (2) wants to use it on that particular system and (3) has access to that particular system.

A lot of the analysis in the comments here does not seem to be taking all of these requirements into account. They are particularly relevant in this case because, I believe, the exploit is a local privilege escalation for people with shell access.

</comment><comment><USER22> I recently reported a security issue to a quite popular open source project (which has at least some company support). The fix is ready but because of coordinating other security fixes into one big release it is - after almost 2 month - still not released. I wonder if this is normal? What else can you do? Full disclosure?

<comment><USER4> It is normal, but not desirable. You should feel free to exercise full disclosure if the vendor is not being responsible.

> [W]ithout the threat of full disclosure, responsible disclosure would not > work, and vendors would go back to ignoring security vulnerabilities.

[https://www.schneier.com/blog/archives/2012/06/on_securing_p...](https://www.schneier.com/blog/archives/2012/06/on_securing_pot.html)

</comment></comment><comment><USER23> To ensure that test kits, catches and patches prevail. But that's only a guess.

</comment><comment><USER13> Obfuscate the hell out of the PoC, then release it simultaneously.

</comment><comment><USER24> Increases the need for Qualys security tools, no?

<comment><USER25> Just the opposite. Releasing a PoC means that /other/ security companies can add the exploit to their behavioral databases that much quicker.

</comment></comment><comment><USER26> self advertisement??</comment>


What is the best comment in source code you have ever encountered? - <AUTHOR> http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered <comment><USER2>
      loop
        ...
        ...
        // sleep 10
        sleep 7 // Changed from "sleep 10" on 11-19-05
                // by jvj because Bruce in Buffalo bitched
                // that it ran too long.  Now he's happy.
                // The next time he bitches, change it to
                // "sleep 5".  That oughta buy us another
                // year before we have to rewrite it.
        ...
        ...
      until done do repeat

<comment><USER3> The speed up loop: <http://thedailywtf.com/Articles/The-Speedup-Loop.aspx>

Although I guess the punchline has come before the "joke"...

</comment></comment><comment><USER4> There's some great stuff in there. I really liked this one:

      // somedev1 -  6/7/02 Adding temporary tracking of Login screen
      // somedev2 -  5/22/07 Temporary my ass

([http://stackoverflow.com/questions/184618/what-is-the- best-c...](http://stackoverflow.com/questions/184618/what-is-the-best-comment- in-source-code-you-have-ever-encountered/778275#778275))

</comment><comment><USER5> There are lost of great ones. I especially liked this _practical_ comment:

From the SO answer:

This seems to stop morons from messing my code...

// Autogenerated, do not edit. All changes will be undone.

[http://stackoverflow.com/questions/184618/what-is-the- best-c...](http://stackoverflow.com/questions/184618/what-is-the-best-comment- in-source-code-you-have-ever-encountered/740603#740603)

<comment><USER6> Then someone who's perhaps a bit too clever for his own good can introduce a new script into the build process so it makes some changes after the file is generated.

</comment></comment><comment><USER7>
        #Christmas tree initializer
        toConnect = []
        toRead =   [  ]
        toWrite = [    ]
        primes = [      ]
        responses = {}
        remaining = {}

[http://stackoverflow.com/questions/184618/what-is-the- best-c...](http://stackoverflow.com/questions/184618/what-is-the-best-comment- in-source-code-you-have-ever-encountered/780361#780361)

</comment><comment><USER8>
        char  program [1];/* Unwarranted chumminess with compiler. */

First by Dennis Ritchie in his regular expression implementation, and then subsequently copied with the comment intact into all other regular expression implementations ever written.

<comment><USER9> Reference for non-C hackers: <http://c-faq.com/struct/structhack.html>

</comment></comment><comment><USER10> I hate the way SO only remembers you for a week or two, so when you return, you have to login, going to a separate screen and so on. Why do they have to make it so hard? What's the advantage in forcing frequent logins?

Yeah, I know I should find some other StackExchange site, go there, create an account there, login there, and post this complaint there - but you know, that's just more of the same problem. </rant>

<comment><USER11> Er.. what? We can't reproduce this, and there are sites in the network I don't visit very often, too.

Please note we did force logout globally, network-wide in April 2010 (to mandate emails for Google GMail OpenIDs) and September 10th 2010 (to enable global auth for all users).

Also, we delete any sessions older than 4 months as a matter of course.

So if you visit VERY infrequently, you might run into one of those.

Details:

<http://blog.stackoverflow.com/2010/04/openid-one-year-later/> [http://blog.stackoverflow.com/2010/09/global-network-auto- lo...](http://blog.stackoverflow.com/2010/09/global-network-auto-login/)

</comment></comment><comment><USER12>
      /**
       * Today I'm getting discharged from the Army
       * Don't have time to properly comment the code
       * Call me if you have any questions: Name,054-XXXXXXX
       */

<comment><USER13> Now that is dedication!

</comment></comment><comment><USER14> My favorite of all time was

      // Michael, this is brilliant!

Yeah, somebody else had complimented a change I'd made a few months earlier. I still maintain that code occasionally, and it's the only comment left I didn't write myself. I leave it there just to get that little ego boost every couple of years.

</comment><comment><USER15> From an educational app:

if($_GET["action"] == "score") {//that's what she said

</comment><comment><USER16>
      // I got this code from [Bob] of [Some other group].
      // I don't know how it works; ask him.

[Bob] happened to be my manager at the time, and hadn't worked for [Some other group] for around five years.

</comment><comment><USER17> In a parser for a config file:

      if (line[0] == '#') continue;   // comment

</comment><comment><USER18> <http://www.dillerdesign.com/experiment/DD_belatedPNG/>

(a PNG-fix for IE6)

// PLEASE READ:

// Absolutely everything in this script is SILLY. I know this. IE's rendering of certain pixels doesn't make sense, so neither does this code!

</comment><comment><USER19>
        // I have to put this part in because Ken is a dick

</comment><comment><USER20> I once wrote a haiku to a particularly nasty bug where the offending line had been. I got a call years later when someone found it, they appreciated the humor.

</comment><comment><USER21> You are not expected to understand this.

</comment><comment><USER22> "This ain't pretty but neither are you."

</comment><comment><USER23> /* Does your mother know you're reading this stuff? */

</comment><comment><USER24> // Don't even ask

Found years ago in Adobe's ActionScript core classes.

</comment><comment><USER25> You just obliterated like 3 hours of my time. Good job!

</comment><comment><USER26> This one: [http://stackoverflow.com/questions/184618/what-is-the- best-c...](http://stackoverflow.com/questions/184618/what-is-the-best-comment- in-source-code-you-have-ever-encountered/184673#184673)

</comment><comment><USER27> From xterm's main.c:

         /*
          * 				 W A R N I N G
          *
          * If you think you know what all of this code is doing, you are
          * probably very mistaken.  There be serious and nasty dragons here.
          */

</comment><comment><USER28> stop(); // Hammertime!

<comment><USER29> I love it! :) The best one so far! I'm still laughing my ass off!

</comment></comment><comment><USER30> """ This code will be documented when someone get convinced that it is impossible to understand what it is doing """

</comment><comment><USER31> <http://www.flickr.com/photos/straup/2801691670/>

</comment><comment><USER18> [http://textpattern.googlecode.com/svn/releases/4.2.0/source/...](http://textpattern.googlecode.com/svn/releases/4.2.0/source/textpattern/publish.php)

$html = parse($html); // the function so nice, he ran it twice

</comment><comment><USER32> Here's a category interface in a shipping iPhone app of mine:

        @interface UIScreen (AppleAreAssholes)
        + (CGRect) convertRect:(CGRect)rect toView:(UIView *)view;
        @end

</comment><comment><USER33> I once left a comment to the effect of

// This code is pretty dense so I recommend you read the documentation first

Some months later I found a follow-up comment left by a fellow dev:

// Or you could just give up now

</comment><comment><USER34> # Do this twice because its stupid and won't work once

# I apologize for how messy this is. Blame it on an inconsistent database structure. I did the best I could.

</comment><comment><USER35> Good funny post, that was the best laugh I've had all day. Thanks!

</comment><comment><USER36> while (6!=9) // Hendrix loop {...}

</comment><comment><USER37> try {

      ...

} catch exception {

// Failed to load in the proper way

// Attempting to wing it

...

}

</comment><comment><USER38> the best comment is the empty one ;)

//

</comment><comment><USER39> Maybe something like this...

//How's my coding?

//1-800-NO-ONE-CARES

Although I had trouble coming up with what to say in the phone number. Any suggestions?

</comment><comment><USER40> Not to be a grouch, but most of this seems puerile and borderline irresponsible to me. Source code should be concise and beautiful, not a repository for unfunny attempts at humor by programmers.

<comment><USER41> I agree.

<comment><USER42> seems to be a good place to get "-4" karma</comment></comment></comment>