in reply to I failed today

How do they propose to cope with the security non-updates in core AND especially in 3rd party packages?

I am copy-pasting from a random link https://infosecwriteups.com/python-2-vulnerabilities-c3a3779f6fc:

p = "aa"
temp = input("enter pass: ")
if temp == p:
    print("ahahah")
else:
    print("ssss")

enter pass: p  <<< this is the name of the variable holding the passwo
+rd!
ahahah
oO( lolling lolling lolling lol )

[download]

Edit: the above is a world-first and the record is held by Python: the name of the variable holding the password must be at least as complex as the password itself. Unfortunately with a restricted charset this goes like : a_variable_you_123_will_n3v3r_b3_able_to_guez = "a strong password!". (Also added a comment in code above)

OT: I have written an MIS for a factory in Perl. I have found that the system sending emails to users a useful feature. Then their (outsourced) IT told me that each company mail account has a monthly cost. Because ... they outsource all the factory email services to ... M$, some 365 %*%$^$&*. I can't understand that, unless M$ also signed them up for free insurance for virus and hacking damages. But that would bankrupt them. So, it's an infection which causes them to stare when you tell them what about confidentiality? Why not setup an email server and actually do some real IT rather than acting as a reseller of IT services? Stare. Stare. Stare.

... I am already flipping burgers part-time. Oh well, we will always have Linux

Replies are listed 'Best First'.
Re^2: I failed today
by cavac (Prior) on May 05, 2023 at 11:45 UTC
[reply]
[d/l]
Re^2: I failed today
by atcroft (Abbot) on May 27, 2023 at 05:15 UTC

    I'm no fan of Python myself, but as most of us have seen Perl (mis-)features or improper usage used as examples of why not to use Perl, I feel someone should be intellectually honest enough to call the same when applied elsewere. In the example given, this is the use of a poorly-named feature that somehow survived in versions of Python prior to the 3.x series.

    In the 2.7.18 documentation, it says that input([prompt]) is the equivalent of eval(raw_input([prompt])), and to consider using the raw_input() function for general input from users. Their eval() is similar to our string eval() function, so I ask the question -- If you were writing a Perl script and accepting credentials, can you think of a valid reason to pass the user's input immediately through a string eval? (If you're writing a program that needs to be security-conscious, I expect some thought on the functions one calls, and honest research when testing shows something misbehaving (it was tested, right?).)

[reply]
      so I ask the question -- If you were writing a Perl script and accepting credentials, can you think of a valid reason to pass the user's input immediately through a string eval?

      Of course not.

      Whereas Perl reminds us all the time that accepting unchecked user input is bad practice. And, god forbid, eval()'ing unchecked user input is criminal, Python decides to name the input+eval function input() and the sane just-input function as ... raw_input(). Why penalise the sane and common practice with more keystrokes? But you are right that reading the documentaton is key to avoid input() misbeheaving and fall in this trap.

[reply]
[d/l]
[select]
Re^2: I failed today
by LanX (Saint) on Apr 13, 2023 at 13:15 UTC
[reply]
[d/l]
      $ python2  --version
Python 2.7.18

      [download]

      at least

[reply]
[d/l]
[reply]

In Section Meditations