@mgorny someone probably has a project that they don’t want to migrate to a new test system, but want to use on more recent versions of python.
Software is never truly dead.
Hence we need to be careful when creating it, especially if we put it out there, if it gets even a small user base, it could have consequences for decades.
@slamr@HauntedOwlbear i found their products in a place near me, not cheap (cheese is not cheap in the first place, but you do pay more for less here), but i tried the camembert and the blue cheese and was blown away by the latter, the camembert is not bad at all, but the blue cheese is next level, really creamy and tasty. Really worth the price imho. Thanks for sharing about them!
@tokyo_0@cazabon yes, the "and" will ensure the result of "in" is used if needed. the code is similar to:
if not Ecryption.AES: . . . flag = False else: . . . flag = "FLAG" in stream
but i commonly need to check/rethink if "not" affects the whole "and" expression 😅.
regarding compile/run time, python does most things on the latter, and doesn't optimise this kind of expressions, because the language gives you too much freedom to be able to check they are valid.
Here your test probably assumes the value is True or False, but it could be something else, like either a string containing a key, or None, or a custom object or None.
@tokyo_0@cazabon "and" and "or" will short-circuit if the first part is enough to know the result.
>>> def spy(value): ... print("called with", value) ... return value ... >>> spy(True) or spy(False) called with True True >>> spy(True) and spy(False) called with True called with False False >>> spy(False) and spy(True) called with False False
so "in" will only be called if the value before the and is "truthy", which means that bool(value) returns True.
@statsguy sms is widely considered unsecure, yes, as it's possible to fraudulently clone a simcard, and get the sms instead of you, an app generated code doesn't have this issue, as they don't need communication, the code is time + key based, and if they did, they could communicate through encryption.
@statsguy NP, regarding the "need" part, that i had forgotten to answer, of course maybe not *all* apps need it, but one should not underestimate the ability to move "laterally", from gaining access to an apparently low criticity account/app, to others, by leveraging it for say, impersonation, or digging information that could help further attacks, email is of course the most obvious failure point, everyone has all their secrets in it, but social accounts can be used to extort money from friends
@statsguy Personnally i use freeotp+ for "one time passwords" like this, unless there is a specific app to use for the service, as this one is open sources and allows me to export my config in a file to save securely somewhere, in case my phone is stolen or lost (because yes, it can be a big problem if you lose your phone).
@statsguy so it’s really better to just be safe(r) by default, and give as little as possible an attack surface so say, if a state actor is working against you, you are certainly still in trouble, but if it’s "just" a bunch of scammers, at least you are not an easy prey for them, it’ll cost them too much time/money to get you to you hope for a worthy reward.
@evan fair enough, your post just got me curious about what it was, and I still am, I'm not even necessarily against these things, they are just pretty different from the ethos I see around here, but I'm glad people are experimenting things with the protocol.