The client sends the request headers (including the x-amz-content-sha256 header) to the signer, and the signer responds with a valid S3 PUT request (minus body). The client takes the signer's response, appends its chosen request payload, and uploads it to S3. With such a system, you can implement a signer in a lambda function, and the lambda function enforces the content-addressed invariant.

Unfortunately it doesn't work natively with multipart: while SigV4+S3 enables you to enforce the SHA256 of each individual part, you can't enforce the SHA256 of the entire object. If you really want, you can invent your own tree hashing format atop SHA256, and enforce content-addressability on that.

I have a blog post [1] that goes into more depth on signers in general.

[1] https://josnyder.com/blog/2024/patterns_in_s3_data_access.ht...

This situation would have been a moving violation. It sounds like the law has not caught up with the concept that a company might hold a driver's license and be issued moving violations.

The goal of an LVT is to insulate a landowner's tax bill from being affected by their own improvements. Its anti-goal is to insulate a landowner from changes in land use around them.

The two downsides I'm aware of are difficulty in transitioning to an LVT and difficulty in valuing the land.

Transitioning to an LVT means that landowners no longer capture land rents for themselves, which is a massive overnight loss in the value they hold. The solutions there typically tax only the difference in land value versus a baseline assessment. So if a lot is worth $100 before LVT and $105 after, the tax is calculated only on the $5 difference.

Valuing the land is tricky because the whole point of LVT is to tax only the location itself. So the value of any structures should be excluded from taxation, and even improvements in soil quality (e.g. on a farm) should be excluded. This is problematic because the market for bare land is significant less liquid than improved land, especially in suburbs and cities. So there isn't always good data on comparable land, and there isn't a way to hold a straightforward auction to value a given lot. Of course, most present systems of property taxation are subject to the exact same issue.

The problem eventually reduces to Ken Thompson's "Trusting Trust" [1] problem. There's no way to externally validate the honesty of any system (cryptocurrency, or otherwise).

[1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Layer 7 solutions provide so much more capacity for granular AuthZ, and thereby eliminate the "soft underbelly" of corporate networks.

https://gist.github.com/hashbrowncipher/17a92c6afb9642503876...

Remote: No preference

Willing to relocate: No

Gist: SRE with a focus in databases; additional specializations in security, automation, and performance

Technologies: online databases (Cassandra, MySQL, Postgres), Python, Terraform, Puppet

Résumé: https://drive.google.com/file/d/1nVQj1w1KK6rLBp_k8dGuSUFO706...

Email: josh@code406.com

I think that Naur's "Programming as Theory Building" (1985) communicates this idea succinctly and forcefully. It's not a textbook, though.

Comments URL: https://news.ycombinator.com/item?id=21777716

Points: 3

# Comments: 0

Every argument I've seen from rurban is predicated upon the assumption that the seed will be leaked by the application, either by directly leaking the key's contents or by an algorithmic attack on the output of the algorithm. As you mention, the former would constitute a grave vulnerability in the application (the kernel, in this case). The latter would constitute a grave vulnerability in the algorithm.

As for assessing whether there are vulnerabilities in the algorithm, we have an academic field (cryptanalysis) that exists to inform us when such vulnerabilities exist. Cryptanalysts' efforts have given us substantial assurance that the algorithms we use everyday (e.g. AES, HMAC, ChaCha, GMAC) are both pseudo-random and adequately prevent disclosure of their keys. SipHash was explicitly designed to be resistant to cryptanalytic attack, by two well-regarded cryptographers (Bernstein and Aumasson). They designed it targeting a specific cryptographic strength/performance trade-off, and to my knowledge it is the best contender for building a flood resistant hash table.

zx2c4, I look forward to using your code. Thank you for making the Linux kernel more secure.

We've found that deploying cronjobs onto individual hosts is quite powerful, and helps us fill a niche between configuration management tools (like Puppet) and specialized coprocesses (like Smartstack). We have cronjobs for downloading code deploys, showing Sensu state within the motd, reconfiguring daemons (especially the Smartstack ones), and (of course) cleaning up unused data.

Of course, there's also the separate problem of scheduling and coordinating tasks across an entire cluster. In most cases we don't use our cron daemons for this, although we do have some jobs that run on multiple hosts and enforce mutual exclusion by grabbing a lock in Zookeeper.

[1] https://github.com/Yelp/puppet-cron#puppet-cron

The only other qdisc I have much experience with is sch_netem, which emulates behaviors of a WAN (delay, loss, etc). I used it in this post [2] to conduct adversarial testing of MySQL replication (search 'tc qdisc').

[1] http://lxr.free-electrons.com/source/net/sched/

[2] http://engineeringblog.yelp.com/2014/03/mysql-replication-ne...