in reply to Re^9: Ideas for "fixing" PerlMonks 1.0
in thread Ideas for "fixing" PerlMonks 1.0

> Is it a deal-breaker?

I need to apply patches to the node in question to code efficiently, yes.

> Then don't. But don't then complain when others take the same attitude.

Ok if there are no plans to hash the passwords, why bother?

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

  • Comment on Re^10: Ideas for "fixing" PerlMonks 1.0

Replies are listed 'Best First'.
Re^11: Ideas for "fixing" PerlMonks 1.0
by erzuuli (Cannon) on Dec 18, 2024 at 21:46 UTC
    I need to apply patches to the node in question to code efficiently, yes.

    You write 'em, we'll apply 'em. Yes it goes slower, but it will still be faster than the current pace of development!

    Ok if there are no plans to hash the passwords, why bother?

    What do you mean by "plans"? Obviously we'd all like to see improvements made. Simply goading the gods isn't how it happens. If you can provide coding & subject matter expertise, we can work together.

      Ok, look.

      If I can apply the patches on that isolated node it'll take me probably a week, considering all edge cases and the weirdness of the monastery. ¹

      If I have to wait for you guys to act, it'll take a month at least.

      Sorry, no!

      Maybe I'll find time next year to locally set up the old download version of the Everything engine and can develop it locally on my box.

      Provided Everything::MAIL.pm is the same. Then you'll get a full node in one go, without patch/dev history.

      Or maybe etj will do better and faster.

      On another note:

      I've reported a serious security issue in 2019 and provided code to patch Everything.pm.

      No matter how you patch it - I don't really care anymore if disabled or optional - please patch it.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

      Updates

      ¹) The necessity to document and test it included.

      There is also injection detection logic to report if someone tried to manipulate the parameters.

      It's also limiting the time window and reset attempts to a fixed number per interval to block DNS and brute force attacks.

      We are talking about hundreds of LOC.

        If I have to wait for you guys to act, it'll take a month at least

        That's the pace at which things move around here. If you want to be involved, you probably ought to get used to it. That being said, we could maybe schedule some time — like an hour per week, or whatever — when we can coordinate, chat in real time, and so on. That should make things go quicker.

        Provided Everything::MAIL.pm is the same. Then you'll get a full node in one go, without patch/dev history.

        That would be great! For sending email, we use this function, node2mail, which is defined in Everything/MAIL.pm. It's dead simple. I'm not sure if EE has functionality to receive email. Will that be needed?

        I've reported a serious security issue in 2019 and provided code to patch Everything.pm.

        Please give me a link to the patch and discussion. (Note: it will probably take Corion to make such a change.)

        Today's latest and greatest software contains tomorrow's zero day exploits.