• (nodebb)

    Visibility is something a lot of people struggle, to this day I encounter devs that have no idea what "internal protected" means even though it's around for nearly 25 year.

  • (nodebb)

    Two possible ways this could be very slightly useful.

    One, it makes it easy to do a text search of the entire code base and find where the function is called from, if you don't trust your IDE to find all references (or if you have even worse WTFs that make it so the IDE can't find all references).

    Two, it stops people from calling the function when they shouldn't. Anyone that tries to call the function will have their brain lock up as they try to figure out WTF is going on with that "password".

  • (nodebb) in reply to Dragnslcr

    Two, it stops people from calling the function when they shouldn't. Anyone that tries to call the function will have their brain lock up as they try to figure out WTF is going on with that "password".

    No, it just makes them dig out the source code for the function to find out what the [REDACTED] password is, and then they dream of consigning the [REDACTED] moronic fucknut who invented such a scheme to the appropriate murky corner of Hell.

  • (nodebb)

    Didn't we already see something like this here, many years ago?

  • Hanzito (unregistered) in reply to Steve_The_Cynic

    That's too black and white. Perhaps this code isn't available in source, and you may overestimate the eagerness of programmers to look through a function's source code. If they do, they'll at least understand they must have a good reason to call this function. If you assume they'll look up the code, they might just as well change private into public. Or call ProcessRequest(RequestType.Unload, Environments.All) directly. Who can tell?

  • Maia Everett (github)

    Java's JMH does something like this:

    https://github.com/openjdk/jmh/blob/master/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java

    if (!challengeResponse.equals("Today's password is swordfish. I understand instantiating Blackholes directly is dangerous.")) {
    throw new IllegalStateException("Blackholes should not be instantiated directly.");
}

if (!challengeResponse.equals("Yes, I am Stephen Hawking, and know a thing or two about black holes.")) {
    throw new IllegalStateException("Who are you?");
}

    But its developers know what they're doing and why.

  • L (unregistered)

    This entire project exists in a single .NET Assembly, and the keyword private is never used once.

    in C# private is the default access level, so this alone is not really a WTF. the fact that everything has been made explicitly public when it shouldn't, might be

  • (nodebb)

    The Linux syscall reboot(2) requires two special magic values to be passed as parameters in order for it to work properly. This is more to prevent accidental invocation—e.g. if some code went awry and started executing Undefined Behavior, you don't want to accidentally call the wrong syscall and reboot the system.

    But it's not a security control. The security control is the fact that only the root user is allowed to call the syscall in the first place.

  • LZ79LRU (unregistered) in reply to Hanzito

    Code review hopefully. /laughs in misery

  • Anon (unregistered) in reply to Steve_The_Cynic

    By that logic, there’s no point making anything private, given that a sufficiently incentivised caller can access it anyway.

    Forcing people to decompile a .dll to find out how to access a function should be enough of a roadblock for them to think that an alternative approach might be easier.

  • Tim (unregistered)

    This reminds me of some code I saw once where the writer tried to do the "are you sure" logic in the business layer rather than in the UI.

    It resulted in the UI having to call the business function twice, once with the areYouSure=false, to which the function would reply "are you sure" and then the UI would have to call it again with areYouSure=true

  • Álvaro González (github)

    I would be really surprised if this even worked, because the first thing I'd expect developers to do is to copy an existing function call with parameters and all.

  • Argle (unregistered)

    Many times and around the world, a group of non-X programmers are told from on high (because a VP's wife's second cousin heard that it's great) to start using X without having any understanding or someone experienced to guide them. Don't believe me? Go look at the original incarnation of MFC.

  • (nodebb)

    private only helps if the "allowed" callers are all in the same class as the callee. If the method needs to be public, you're out of luck.

    I see this as a kind of sanity checking, like the reboot(2) example. Similar to putting a sentinel in a structure parameter. Calling it a "password" makes it seem more significant.

  • Zug (unregistered)

    But surely the real WTF (or at least another one) is that code fails silently; so nobody even knows what went wrong until they fall over some other side effect,

  • (nodebb)

    I love that comment: "It is currently only called from Form1.Closing()", and what it reveals about the project. It's a Windows Forms project, and they didn't even bother changing the default name of the form 🤦‍♂️

  • (nodebb) in reply to MaxiTB

    @MaxiTB: There is no "internal protected" in C#. There is "protected internal", and "private protected".

  • LZ79LRU (unregistered) in reply to tom103

    Maybe they are like me. I have a tradition newer to rename the first form in a project out of superstitious reasons. It upsets the framework. And I genuinely see an uptick of strange behavior if I do so.

  • (nodebb) in reply to MaxiTB

    [quoate]Visibility is something a lot of people struggle, to this day I encounter devs that have no idea what "internal protected" means even though it's around for nearly 25 year.[/quote]

    More like 35 years at least. But yeah, it's irritating.

  • (nodebb)

    Out of interest: How does C# handle a situation, where a non-nullable variable is to be initialized inside an if/else?

    MyType x;
if(condition)
{
    x = firstValue();
}
else
{
    x = secondValue();
}

    If MyType is nullable instead, it would just be initialized to null, but is there some way to declare the variable in the outer scope without making in nullable?

    Basically, I want to know if it is possible for the compiler to guarantee that the variable has been initialized or otherwise, at least at runtime to catch a programming error, where the variable is not.

    In Python, this is one of the reasons I sometimes use ternaries...

    x = firstValue() if condition else \
    secondValue()

    In Fortran, I just have to give up, because it has no short-circuiting ternary form and too many things cannot be expressed as

    value = function()

    anyway, since the lack of move semantics on function returns means that often "output arguments" are the only viable solution.

  • (nodebb) in reply to Anon

    WAITFOR DELAY '0:0:10'

  • (nodebb)
    <script>alert(1)</script>
  • LZ79LRU (unregistered) in reply to R3D3

    The C# compiler will recognize if there is any situation where the variable remains uninitialized before it is first accessed and will throw up an error. So in your example things will work just fine because all the paths contain an initialized. If the else was missing the init than it would throw up a compiler error.

Leave a comment on “Private Passwords”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article