|
Volguus posted:Yeah, me as well, based on the quoted javadoc though. os::random() .... wouldn't have imagined. Christ alive! And as a default, too. 
|
#
?
Apr 26, 2018 05:07
|
|
|
|
| # ? Jun 5, 2024 08:01 |
|
|
Makes sense. Actually hashing things is slow, and all you really need is an identifier that hopefully doesn't collide. Random also means that it's harder to find a way to rely on the particular implementation.
|
|
#
?
Apr 26, 2018 10:49
|
|
|
There's a very specific reason to use randomness here. If you don't randomize hashes intended for O(1) lookup algorithms you open yourself up to DOS attacks whenever a malicious user is able to control the values that get hashed, for instance through a web server or a command line interface. If the exact hash algorithm is known ahead of time and you're able to pass a bunch of keys into a hash table, you can create lots of strings that collide, causing performance to degenerate drastically in some cases. You can effectively turn hash tables into linked lists. This is an attack vector that's been discovered and rediscovered multiple times throughout the history of programming. I believe the Java implementation goes back to 2011, when a couple of guys demonstrated that you could bring lots of websites to their knees simply by visiting a URL with lots of query parameters. This article is a good summary: https://medium.freecodecamp.org/hash-table-attack-8e4371fc5261 And a video from back then: https://www.youtube.com/watch?v=R2Cq3CLI6H8 Edit: On reflection, I'm not sure if the os:random() call in the default implementation in Java is actually related to this vulnerability, since that should mostly be relevant for strings. It may just be there to dissuade people from relying on precise hash values. LOOK I AM A TURTLE fucked around with this message at 14:30 on Apr 26, 2018 |
|
#
?
Apr 26, 2018 12:40
|
|
|
CPColin posted:It's hilarious that HotSpot has a command-line argument for which hash code algorithm you want. It's sad that somebody somewhere has probably had to use it. And you're sure nothing in your stack/environment sets it? How sure? 
|
|
#
?
Apr 26, 2018 13:57
|
|
|
LOOK I AM A TURTLE posted:Edit: On reflection, I'm not sure if the os:random() call in the default implementation in Java is actually related to this vulnerability, since that should mostly be relevant for strings. It may just be there to dissuade people from relying on precise hash values. It isn’t related. This vulnerability is fixed by modifying the hash table implementation, not by randomising hash codes - you need hash codes to be deterministic whenever equality is different from identity, and java specifies exactly what algorithms must be used to compute them for many types.
|
|
#
?
Apr 26, 2018 19:26
|
|
|
It's related in the sense that you wouldn't want the hash codes of successively-allocated objects to exhibit obvious and deterministic patterns, as it is imaginable that an attacker could figure out that a particular request will get a particular server to allocate a number of identity-hashed objects and then insert them into a hash table.
|
|
#
?
Apr 26, 2018 22:44
|
|
|
Haven't found the horror yet. But I'm looking into a very unperformant report that I was told I ruined by adding an outer join too. We use a custom query builder for most of our sql operations and maps via some annotations on a model object. Query runs in 2 seconds. 20 minutes later it has mapped all the rows. Mapping a single row takes longer than the query.
|
|
#
?
Apr 26, 2018 23:16
|
|
|
Rubellavator posted:Haven't found the horror yet. But I'm looking into a very unperformant report that I was told I ruined by adding an outer join too. We use a custom query builder for most of our sql operations and maps via some annotations on a model object. Using a query builder is not necessarily a bad thing. Using a query builder because the users do not know SQL is. Teach those users SQL and ditch the query builder (it becomes useless at that point).
|
|
#
?
Apr 27, 2018 00:03
|
|
|
Sounds like the mapper is the horror anyway if it takes that long to map a single record. I don't even know how you'd make it that slow, really curious what you find out.
|
|
#
?
Apr 27, 2018 00:09
|
|
|
found some code today that was probably written before Java String.split, which used String.indexOf to split on tab characters and deserialize a TSV
|
|
#
?
Apr 27, 2018 00:14
|
|
|
Tarezax posted:found some code today that was probably written before Java String.split, which used String.indexOf to split on tab characters and deserialize a TSV inexcusable, considering that StringTokenizer has been there since jdk 1.0
|
|
#
?
Apr 27, 2018 07:55
|
|
|
necrotic posted:Sounds like the mapper is the horror anyway if it takes that long to map a single record. I don't even know how you'd make it that slow, really curious what you find out. Turns out it has something to do with the derby jdbc driver. Its the actual resultset.next () call that is taking so long. My suspicion was the fetchsize but increasing that did nothing.
|
|
#
?
Apr 27, 2018 15:58
|
|
|
Not a horror, but I've been writing some LDAP code for the first time in my life and I found this in one of the many, many, many (many!) specifications:pre:2.11. drink
The 'drink' (favoriteDrink) attribute specifies the favorite drinks
of an object (or person), for instance, "cola" and "beer".
( 0.9.2342.19200300.100.1.5 NAME 'drink'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
in [RFC4517].e: I love that it's also case-insensitive and searchable hackbunny fucked around with this message at 17:51 on May 3, 2018 |
|
#
?
May 3, 2018 17:31
|
|
|
hackbunny posted:Not a horror, but I've been writing some LDAP code for the first time in my life and I found this in one of the many, many, many (many!) specifications: If you need to plan a lunch meeting for a bunch of execs, might be useful 
|
|
#
?
May 3, 2018 17:58
|
|
|
I have this mental image of the X.500 guys raiding their secretaries' rolodexes for ideas on what fields they should include in the person class
|
|
#
?
May 3, 2018 19:09
|
|
|
https://www.bleepingcomputer.com/news/security/somebody-tried-to-hide-a-backdoor-in-a-popular-javascript-npm-package/quote:According to the npm team, the backdoor "allowed for an attacker to input arbitrary code into a running server and execute it."
|
|
#
?
May 3, 2018 19:35
|
|
|
Hey, guess what? Twitter accidentally had everyone's passwords in plaintext due to a bug. (Bonus: right now on the website their settings page where you can change your password is broken and leads to an error. The app apparently works) Linear Zoetrope fucked around with this message at 23:19 on May 3, 2018 |
|
#
?
May 3, 2018 23:17
|
|
|
code:
|
|
#
?
May 4, 2018 00:04
|
|
|
Linear Zoetrope posted:Hey, guess what? Twitter accidentally had everyone's passwords in plaintext due to a bug. I once turned on audits for a certain Oracle product and it logged all the user defined encrypted fields into a table in plaintext. The metadata lookup was case sensitive and bulk imported fields were in the wrong case, so it couldn't find the metadata and just spit it out in plaintext. Rubellavator fucked around with this message at 00:18 on May 4, 2018 |
|
#
?
May 4, 2018 00:13
|
|
|
Linear Zoetrope posted:Hey, guess what? Twitter accidentally had everyone's passwords in plaintext due to a bug. drat. Thank goodness I use randomly generated passwords. Time to rotate this one.
|
|
#
?
May 4, 2018 00:17
|
|
|
Zaphod42 posted:drat. thank goodness my twitter password is 1234. I never forget them. Now, if i'd only be able to remember the usernames ....
|
|
#
?
May 4, 2018 05:17
|
|
|
CPColin posted:
This gives me recalls to the codebase I'm currently going through. Additionally - not much was ever deleted
|
|
#
?
May 4, 2018 07:02
|
|
|
Here's a fun one. You execute the following query (nevermind why):code:Can anyone guess why that happened? It's lovely.
|
|
#
?
May 10, 2018 03:17
|
|
|
There's an update trigger on the table that tries to set the primary key equal to bar_id?
|
|
#
?
May 10, 2018 03:23
|
|
|
So https://www.bleepingcomputer.com/news/microsoft/microsoft-adds-support-for-javascript-functions-in-excel/ of course https://www.bleepingcomputer.com/news/security/poc-developed-for-coinhive-mining-in-excel-using-custom-javascript-functions/
|
|
#
?
May 10, 2018 03:26
|
|
|
TooMuchAbstraction posted:There's an update trigger on the table that tries to set the primary key equal to bar_id? Nope, it actually has almost nothing to do with the bar_id column itself.
|
|
#
?
May 10, 2018 03:32
|
|
|
Steve French posted:Here's a fun one. You execute the following query (nevermind why): It touched a row that's already violating the unique constraint on the primary key?
|
|
#
?
May 10, 2018 04:22
|
|
|
b0lt posted:It touched a row that's already violating the unique constraint on the primary key? Oooh, that'd be a good one. The answer: The table had an auto increment id column. The primary key was _not_ this id column, but instead a composite of the id column and the created_at column. The created_at column was configured with "on update CURRENT_TIMESTAMP". For any given bar_id, it was likely for there to be multiple rows with the same id, but different timestamps.
|
|
#
?
May 10, 2018 04:30
|
|
|
If it's autoincremented, how can it be the same number in multiple rows?
|
|
#
?
May 10, 2018 04:41
|
|
|
Volguus posted:If it's autoincremented, how can it be the same number in multiple rows? You can still assign an explicit value on creation or modify it on update.
|
|
#
?
May 10, 2018 04:43
|
|
|
DaTroof posted:You can still assign an explicit value on creation or modify it on update. But why would ... oh, I see. Yup, they deserve it. Whatever happens, they completely deserve it.
|
|
#
?
May 10, 2018 05:02
|
|
|
Sacrifice the original schema's designer to the gods of normalization.
|
|
#
?
May 10, 2018 14:53
|
|
|
Nth Doctor posted:Sacrifice the original schema's designer to the gods of normalization. The schema is stupid, but not as stupid as developers updating/assigning an autoincrementing column. The current schema would at most have a performance and database size impact. Probably negligible on both sides. Overriding the autoincrement in any way makes it completely useless.
|
|
#
?
May 10, 2018 15:08
|
|
|
Volguus posted:The schema is stupid, but not as stupid as developers updating/assigning an autoincrementing column. The current schema would at most have a performance and database size impact. Probably negligible on both sides. Overriding the autoincrement in any way makes it completely useless. "Then we can just make up our own nice, readable numeric IDs without having to query the database to see what it came up with" - 
|
|
#
?
May 10, 2018 15:22
|
|
|
Volguus posted:The schema is stupid, but not as stupid as developers updating/assigning an autoincrementing column. The current schema would at most have a performance and database size impact. Probably negligible on both sides. Overriding the autoincrement in any way makes it completely useless. It appears that in practice, the autoincrement ID is not used at all, and the ID is always set on insert (this appears to be some sort of annotation table for something else where these IDs are predetermined). So while setting an autoincrement ID is stupid, it's more that the column is autoincrement when it shouldn't be. What bothers me here is having a composite primary key where part of the key is automatically updated whenever the row is modified.
|
|
#
?
May 10, 2018 17:04
|
|
|
In very early versions of our software decades ago, we only had one, global sequence that each table pulled from to populate its own sequence column. This was back when the insert time was also set to be a unique constraint. They did a lot of terrible things to get a working prototype to take out for bids.
|
|
#
?
May 10, 2018 20:21
|
|
|
duz posted:In very early versions of our software decades ago, we only had one, global sequence that each table pulled from to populate its own sequence column. This was back when the insert time was also set to be a unique constraint. They did a lot of terrible things to get a working prototype to take out for bids. I have seen that done and I think that's perfectly fine. Especially when using an ORM that is able to prefetch a bunch of numbers and caching them. Nothing wrong with a sequence per table either.
|
|
#
?
May 10, 2018 20:29
|
|
|
Steve French posted:setting an autoincrement ID is stupid Do you mean manually updating an autoincremented ID column, or are you saying that autoincremented UIDs are stupid (which I would need a lot more explanation on)
|
|
#
?
May 10, 2018 20:42
|
|
|
ChickenWing posted:Do you mean manually updating an autoincremented ID column, or are you saying that autoincremented UIDs are stupid (which I would need a lot more explanation on) I mean explicitly setting the value of an autoincrement ID column. Though there _are_ ways that leaning too heavily on autoincremented UIDs can be bad, particularly exposing them pubicly, that's not what I meant.
|
|
#
?
May 10, 2018 23:48
|
|
|
|
| # ? Jun 5, 2024 08:01 |
|
|
programmers who refuse to use IDE's are the absolute worst. Every, single, loving time I open up code from a programmer that refuses to use a IDE, it's just a sea of red and yellow bullshit.
|
|
#
?
May 11, 2018 00:05
|
|
