5 ms·

Haskell could and would absolutely prevent this problem. Haskell does not work by aggregating together the features that a whole system needs. It works by brea

Haskell could and would absolutely prevent this problem. Haskell does not work by aggregating together the features that a whole system needs. It works by breaking down permissions per function. You would immediately see that a function which was only ever meant to do context lookups also has network access. This would be such a crazy type for such a simple function that no one would write it this way. Don't think about it as aggregating effects, think about it as, all of the leaves of the system have the most narrow permissions possible. And that's where most bugs are, in the leaves.

MichaelBurge 5y ago
If I were writing Haskell logging functions, I would use the type "String -> IO ()" and it could do whatever it wanted including network access. I might distinguish resolveFormatString :: String -> [List Parameter] -> IO String" resolveFormatStringSafe :: String -> [List Parameter] -> String but it wouldn't be "most narrow permissions possible". It would be "everything or nothing".
- light_hue_1 5y ago
  You would never spot this the edge of the logging API. In any case, it's easy to see this can't be the right mental model for security in Haskell. main is `IO Int` so at a gross level you can't say anything about an API or a program. Security in Haskell is about internal guarantees. The developers of the library would immediately spot that their call does a lot more than it was ever supposed to locally. They would have a function that has a crazy permissive type like IO instead of something very narrow related to the specific functionality they need to do their one lookup.
  - chii 5y ago
    > The developers of the library would immediately spot that their call does a lot more than it was ever supposed to locally but the point was that if the feature is intentionally developed, then the type signatures would reflect it - it doesn't do "a lot more than it was ever supposed to". Type systems don't tell you that a logging library shouldn't access the network. It just tells you that it does, and if this feature was intentional, then how would the type system flag it differently from a cURL-like library that writes to disk with data from the network?
- thesz 5y ago
  And you should use the type "Log m => String -> m ()" instead of general IO. This way, for one example, you can log in some State-derived monad, keeping logs for caller to extract and use. It is as safe as pure function. And, of course, it is trivial to implement in IO.
lelanthran 5y ago
> You would immediately see that a function which was only ever meant to do context lookups also has network access. I still don't see how that would help - this logging library was SUPPOSED to have network access. Would a user pause to wonder what the network access is for when it's literally part of the featurelist?
- light_hue_1 5y ago
  Because in Haskell, you don't give the library permissions. It doesn't matter if the library had permissions to do something. The library is not an entity. You give functions permissions on a fine-grained basis, permissions which are automatically derived. The specific function which has the bug didn't need network access. It just needed to look something up in the environment. That function would never have a type that gave it network access, that would be insane and a type error.
  - lelanthran 5y ago
    > The specific function which has the bug didn't need network access. My reading of the bug and exploit is that the specific function not only needed network access, it was a intentional feature. > It just needed to look something up in the environment. That's not how I understand it - it parses the user-supplied input, and fetches (and subsequently executes) the package in the user-supplied input. The environment is irrelevant. Now, bearing in mind that this was intentionally put in, and that the feature is working as intended and expected, how would a different programming language help? Even if written in (for example) Haskell, the behaviour will be coded the same way, because that is the intended behaviour.
    - inkeddeveloper 5y ago
      Similar to warfarin. It was intended as rat poison. But then someone said “we should use this for blood thinning in humans.” And then no one questioned why doctors were prescribing rat poison because it had the feature that was desired. Saying, no language can prevent a developer from using something when they very much intentionally use it.

MichaelBurge 5y ago

If I were writing Haskell logging functions, I would use the type "String -> IO ()" and it could do whatever it wanted including network access. I might distinguish resolveFormatString :: String -> [List Parameter] -> IO String" resolveFormatStringSafe :: String -> [List Parameter] -> String but it wouldn't be "most narrow permissions possible". It would be "everything or nothing".

light_hue_1 5y ago
You would never spot this the edge of the logging API. In any case, it's easy to see this can't be the right mental model for security in Haskell. main is `IO Int` so at a gross level you can't say anything about an API or a program. Security in Haskell is about internal guarantees. The developers of the library would immediately spot that their call does a lot more than it was ever supposed to locally. They would have a function that has a crazy permissive type like IO instead of something very narrow related to the specific functionality they need to do their one lookup.
- chii 5y ago
  > The developers of the library would immediately spot that their call does a lot more than it was ever supposed to locally but the point was that if the feature is intentionally developed, then the type signatures would reflect it - it doesn't do "a lot more than it was ever supposed to". Type systems don't tell you that a logging library shouldn't access the network. It just tells you that it does, and if this feature was intentional, then how would the type system flag it differently from a cURL-like library that writes to disk with data from the network?
thesz 5y ago
And you should use the type "Log m => String -> m ()" instead of general IO. This way, for one example, you can log in some State-derived monad, keeping logs for caller to extract and use. It is as safe as pure function. And, of course, it is trivial to implement in IO.

lelanthran 5y ago

> You would immediately see that a function which was only ever meant to do context lookups also has network access. I still don't see how that would help - this logging library was SUPPOSED to have network access. Would a user pause to wonder what the network access is for when it's literally part of the featurelist?

light_hue_1 5y ago
Because in Haskell, you don't give the library permissions. It doesn't matter if the library had permissions to do something. The library is not an entity. You give functions permissions on a fine-grained basis, permissions which are automatically derived. The specific function which has the bug didn't need network access. It just needed to look something up in the environment. That function would never have a type that gave it network access, that would be insane and a type error.
- lelanthran 5y ago
  > The specific function which has the bug didn't need network access. My reading of the bug and exploit is that the specific function not only needed network access, it was a intentional feature. > It just needed to look something up in the environment. That's not how I understand it - it parses the user-supplied input, and fetches (and subsequently executes) the package in the user-supplied input. The environment is irrelevant. Now, bearing in mind that this was intentionally put in, and that the feature is working as intended and expected, how would a different programming language help? Even if written in (for example) Haskell, the behaviour will be coded the same way, because that is the intended behaviour.
  - inkeddeveloper 5y ago
    Similar to warfarin. It was intended as rat poison. But then someone said “we should use this for blood thinning in humans.” And then no one questioned why doctors were prescribing rat poison because it had the feature that was desired. Saying, no language can prevent a developer from using something when they very much intentionally use it.