If a malevolent script already can alter your HTML, you have bigger problems than it being able to change a hash - it can embed any JS whatsoever.

SRI works by preventing malevolent parties from altering the sources that you request. It's like a checksum that you use to ensure that the downloaded file is correct.

I think the assumption is that the hashed content lives on a different server, e.g. a CDN, than the content that references the hashed content, e.g "the html page." So an attacker would have to modify the hashed content on the CDN as well in every place where the hashed content is referenced

Indeed. Although, to be clear, I was talking about dynamic changes to the HTML page.

more generally: in all cases where you compare a file to a hash, an attacker can undermine by altering the hash, but when an attacker has access to alter the hash, they have already infiltrated much deeper

Was the intent being able to repeatedly def from the repl?

yeah, I was developing some script

but when I only updated one var, the other calls did not see it

Got it Nice to interactively carve out a script in prod :thumbsup:

I always take a shower after doing sql too.

It's also against our community rules about not bashing other languages @U0545PBND so I deleted it.

Err…. okay @U04V70XH6, but that was really tongue in cheek given that lisp, which Clojure falls under, was having both the knight, the horse and the princess stark raving mad after the rescue

Well, it explicitly says that -YYYYYY is fine. However: • https://clojure.atlassian.net/browse/CLJ-2347 • https://github.com/google/closure-library/issues/1142

So now I have this "beauty":

(s/and inst? #(let [y (.getFullYear ^js/Date %)]
                  (< 0 y 10000)))

it says it is fine as long as both parties pre agree to it first, and handling it is optional, and I believe if you are going to use it, it mandates the user +/-, so all dates start with either + or -

and it isn't even year 0 that is the cut off

years before 1583 are not automatically allowed by the standard.

> if you are going to use it, it mandates the user +/- Only if it's 6 digits, if my understanding is correct.

Oh, I'm definitely mixing stuff up because of how js/Date handles it already.

So unnecessary, an epoch in 2000 would have been fine in our product

But also; I kinda enjoy strange timezone stuff. Just because how ridiculous it becomes sometimes.

A very relevant and also very recent XKCD: https://xkcd.com/2519/

yes that kind of stuff is amazing

For one, The Netherlands used to have a timezone of +00:19:32, because someone measured the exact distance between Amsterdam and Greenwich

this is why the naive way of writing date generators for generative testing (just generate integers) is bad. you end up finding bugs with dates so far in the past or future you don't care about them

(which is what clojure does by default for inst?)

yeah, we have some pretty ridiculous period generation because of that

like, either very VERY long periods. Or zero duration somewhere in the far future

ideally you break a date into its component parts write a generator for each part with the proper ranges, and then assemble them into a date

the other way is to generate deltas from now, generate random integers and add them to the current date

yeah that was what I was thinking

although, now is side effectful, wouldn’t that mess with reproducibility

yes

it depends on your tests how likely that is to break things

> you break a date into its component parts write a generator for each part with the proper ranges Wouldn't it immediately create issues with leap years and seconds and whatever else might exist? Or would such a generator simply always skip them?

there are a number of issues you have to decide what yo do with, like when your generate a month of 2 and a day from 29 to 31

for leap seconds it is easy enough, iso8601 specifcally allows for seconds to be 00 to 60 instead of 00 to 59, so the range of seconds just needs to be larger, then when asembling the date you decide what to do with leap second (if it isn't the end of a month get rid of it?)

I'd use the approach of adding a random number of seconds to a base date, but with a set date instead of (now) as the basis. Like the date as of when you first implemented this scheme. Then you can set the range to +/- 100 years or whatever

15 in which calendar? 😅