benmmurphy
Joined 15 years ago
Joined 15 years ago
Move 6. kd1 after Qxf2+
if they could guarantee hard bounds on how long low priority tasks take to complete they could implement your scheduling algorithm. but i think in reality the low priority tasks are either not boundable or they if they do have a provable bound the bound is too high.
Also, even if DLP is hard for the curves we use algorithms like ECDSA might be a bit fishy. Unlike schnorr signatures there is no proper security reduction for ECDSA.
https://github.com/snowflakedb/snowflake-connector-net/pull/...
but if you have:
X=$(echo "$BLAH")
then in bash I believe this is safe, because bash will just substitute this as putting the BLAH variable as the first argument to echo without doing any further parsing. without the double quotes can be safe as well but more risky.
X=$(echo $BLAH)
and the only difference is bash will split the arguments. so if you have BLAH="x y" then bash will pass two arguments to echo. though, this can be dangerous if the command you are invoking has dangerous command line options.
however, they had something similar to:
TITLE=$(echo '${{ github.event.issue.title }}')
and this ${{ }} is some kind of template substitution that is happening before the command is sent to bash. so if the variable `github.event.issue.title` was `foo bar` then bash sees something like:
TITLE=$(echo 'foo bar')
and then you start to have problems because `'` can be put into the title to escape.
the bash variable substitution will protect you in a lot of cases from command line injection but if you pass user input directly into command evaluation without using variables then bash can't protect you.
For example if it takes 20ms to write a batch to the WAL then if you do 5 updates to the same row then that is a minimum of 100ms. But without waiting on locks if you can batch all the WAL writes together then this could be just 20ms.
I don’t think holding locks while waiting for WAL is strictly necessary. There is definitely some anomalies that can happen if you don’t wait for WAL to be durable because transactions that don’t write WAL can observe non-durable writes in some situations. So for example conditional updates that don’t perform work. But I assume this can be fixed by making these wait on the commit for dependent transactions to become durable if they are empty. There is also the problem of failing writes that reveal information about non-durable writes which is more tricky. For example you try to insert into a unique index and it fails, but the duplicate was due to a non-durable write that is lost.
Pure reads should be fine when using MVCC because you just show the latest durable version of the DB. I know some other replication systems will run all transactions including reads through the WAL/replicated log in order to not have anomalies.
https://github.com/torvalds/linux/blob/master/mm/memory.c#L1...
Assuming addr is a virtual address it probably makes sense that pte_free_tlb does not need it.
https://github.com/torvalds/linux/blob/master/arch/x86/mm/pg...
that sounds like the HSM is capable of generating keys in a range that is smaller than [1..group_order). such a feature makes no sense at all. or is this some kind of weird thing where people want to generate weak keys for 'testing' and HSM vendors have added such a strange feature. its actually satisfying to see someone get burned by this because such a feature should never exist and this is the reason why. if the HSM can generate keys in a smaller range (especially some arbitrary small range) then you are putting a lot of trust in the operators of the HSM. hopefully there are good audit logs and people actually check the audit logs every time keys are generated to make sure the keys being generated aren't from a special range.