3 ms·

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 distin

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.

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.