jeremyevans
Joined 15 years ago
Karma
155
Submissions
39
Member since
Jul 15
Ruby Committer. Author of "Polished Ruby Programming". Lead developer of Sequel, Roda, and Rodauth. OpenBSD ruby ports maintainer.
View on Hacker NewsRecent submissions
Comment · 3 months ago
I've done the same for about 5 years (switched from SendGrid to smtp2go last year). I blogged about it when I first set it up: https://code.jeremyevans.net/2021-07-29-running-my-own-email...
Comment · 5 months ago
Actually, I think most had the code in track 2. Track 1 was an audio track warning you that the disc is only designed to a play on the system. More details at https://retrocomputing.stackexchange.com/questions/27518/did...
Comment · 1 year ago
"freezer" was my originally desired name for this gem, but it was already taken.
Comment · 1 year ago
It's cool to see this posted here. Refrigerator has been around for a number of years, but it doesn't get much press. It was originally developed as part of my work getting production Ruby web applications to run in chroot environments, where you cannot load libraries after chrooting (for more details, see https://code.jeremyevans.net/presentations/rubyhack2018/inde...). This allows you to emulate that type of chroot restriction without superuser access. It also allows you to detect monkey patches of core classes in libraries.
Note that it doesn't prevent or discourage monkey-patching, it just requires that you apply your monkey-patches before freezing the core classes. The idea here is similar to OpenBSD's pledge, where startup and runtime are considered different phases of an application's lifecycle. After startup, you limit what the runtime can do. With refrigerator, you freeze the core classes at the end of startup. So monkey patches are allowed during startup, but not at runtime.
Comment · 4 years ago
There is a Ruby form library named Forme that works this way for Roda and Sequel (https://forme.jeremyevans.net/files/README_rdoc.html#label-R...). As you expect, this makes handling normal HTML form submissions much easier.
Comment · 4 years ago
That I cannot answer (not sure where that link comes from, maybe nonameiguess can tell you). Looks like suppliers.fiscal.ca.gov is a externet location for vendors that do business the state, not a public website.
Comment · 4 years ago
That's the most recent audited report. Auditing the state's entire financial report takes a long time. The report for year ended June 2020 should be published later this month (scheduled for December 22), according to the California State Auditor: https://www.auditor.ca.gov/bsa/aip
Comment · 4 years ago
If you're using X, the fluxbox window manager supports tabbed windows: http://fluxbox.org/
Comment · 8 years ago
> I'd just like to point out that a lot of RDBMSs support storing date and time alongside timezone information directly without using two separate fields. SQL Server has datetimeoffset, PostgreSQL has timestamp with time zone, and Oracle has timestamp with time zone.
PostgreSQL's "timestamp with time zone" doesn't store timezone, it converts the time to UTC and stores that, and on retrieval converts the value to the connection's time zone.
Comment · 9 years ago
That could be the case, but if you are going to open source the application, what would be the point of trying to hide it?
Considering that password hashes are stored in the users table, it seems unlikely. While you can use PostgreSQL to implement per-column permissions, it's a fairly large pain, and you have to make sure every query you are using that selects from the table does not select that column. Rails/ActiveRecord by default selects all columns in the model's table, and it's a fair amount of work to work around that.
Comment · 9 years ago
Restricting access to the password hashes using database security so that a vulnerability in the web application cannot expose password hashes unless a separate vulnerability in the database was also exploited. In PostgreSQL (and other SQL databases), this generally involves having multiple database users with separate permissions, making it so that the database user the web application uses doesn't not have SELECT permissions for the password hash column.
If you want an example for a Ruby authentication library that does this, there is Rodauth: https://github.com/jeremyevans/rodauth
Comment · 9 years ago
In case you are wondering how it handles password encryption and storage, it appears to use a custom password hash based on SHA256 and scrypt: https://github.com/18F/identity-idp/blob/980c2aa26397f530673...
Passwords appear to be stored in the users table in the "encrypted_password" column, and it does not appear that any database-based security is used. This is one RCE/SQLI vulnerability away from exposing the password hashes for all users. To be fair, that's probably true of most sites that store password hashes, but I would have expected better from 18F.
Comment · 10 years ago
That isn't a problem in Sequel, as you can pass a complex expression to #or, in which case it works as you would expect it to:
Post.where(id: 1).or(Sequel.&({:id=>2}, {:name=>'Foo'}))
# SELECT * FROM posts WHERE ((id = 1) OR ((id = 2) AND (name = 'Foo')))