3 ms·

There are PDF readers that do not support the scripting format extensions. Note this does not prevent unscrupulous companies abusing dominant market positions

There are PDF readers that do not support the scripting format extensions. Note this does not prevent unscrupulous companies abusing dominant market positions to voluntarily embed machine and serial hash watermarks. To be clear: formats like pdf, ps, webp, svg, and tiff are so badly implemented in some ecosystems... they can't _ever_ be assumed safe input formats. Thus, at some point people need to spin up an actual VM to transcode a "web" version, and scrub each stage of the rendering pipeline like a virus or header injection is already present. "I never play where nice things are, and don't break things" (Eliza Mowry Blven, The Humanitarian Review, Volume 3, March, 1905) Cheers =3

tialaramex 2y ago
I worked with TIFF pretty extensively, it's a mess but I don't see why a WUFFS TIFF codec can't be fine. What makes you say you need "an actual VM to transcode" a TIFF ?
- Joel_Mckay 2y ago
  The complex formats of tiff and tga specifications makes it nearly impossible to span all the edge-cases with unit-tests. A VM can be in a known-state snapshot, process pre/post signature logged/compared with a scripted debugger, and binary input/output stripped of non-compliant metadata/blobs at each stage of the pipeline if the process behaves as expected. I've yet to find a better method than Honeypots to sustainably mitigate the complex leaky dependency mess on traditional architectures. It has been my experience that "all software is terrible, but some of it is useful". It may just be my bias, but I see code smell getting worse in recent decades... Have a nice day, =3 https://www.youtube.com/watch?v=aCbfMkh940Q https://www.youtube.com/watch?v=aCbfMkh940Q
  - tialaramex 2y ago
    So, there's actually no particular reason and if somebody cares to write one then yup, TIFF codec in WUFFS would in fact be safer and faster than your uh, approach.
    - Joel_Mckay 2y ago
      One does not rely on the persistent competence of the coders, and will tell you when something has gone wrong. And walking a binary object store to ban problem users is not always necessary... depending what you are doing. Most other approaches makes the same predictable assumptions: https://en.wikipedia.org/wiki/List_of_cognitive_biases https://en.wikipedia.org/wiki/List_of_cognitive_biases Despite popular belief, shitty design does not usually get better in another language. Rather, people just feel more confident it isn't shit anymore. I have yet to see evidence to the contrary. =3
      - tialaramex 2y ago
        Wait, you believe that somehow one of these approaches doesn't rely on competence from programmers? How do you figure? Have you been imagining that sandboxes are some sort of fairy dust we just stumbled onto one day, supernatural in nature and not, in fact, just software written by people you're hoping are competent and haven't left any holes?
        Joel_Mckay 2y ago
        The point was... one is testing parser/OS integrity via a debugging interface over an expectation of an unchanging emulated environment state... there is nothing particularly special about the approach. Even Qubes OS and RancherVM is not perfect in this regard friend. Or put another way, the available attack surface of a bare-minimum fixed environment is much easier to auto-audit, than a pile of daily permuted binaries and self-delusion approach. i.e. if it fails to behave in an expected way, or is modified in any way... the host audit process doesn't have to care why or how it is broken to maintain a service queue as the guest is culled. Perhaps I am wrong about exchanging 15% of raw performance for reliability, but things can get complicated with licenses and multiple OS specific platforms. You seem to be getting emotional about this subject, presenting secondary and tertiary straw-man arguments. So I'm going to go eat some Cheese Goldfish crackers... and just agree that your beliefs are interesting. Have a fantastic weekend... =3
        2y ago
immibis 2y ago
WUFFS is provably safe - that's the whole schtick. If a WUFFS kernel exists, you can assume it is safe. If it's not proven safe, it doesn't compile. The reason everyone doesn't program in WUFFS is that you have to write a proof that your kernel is safe, which takes a very very very long time.
- deleted 2y ago
  [deleted]
- indolering 2y ago
  What's the formal verification story for WUFFS?
  - Joel_Mckay 2y ago
    If you point out some of the above has run-state in some situations... it is provably nondeterministic... and thus the assertion of correctness is utter nonsense. Hardly a panacea for fundamentally bad designs that go back decades. Ever seen a web-server written in postscript? Its worth a look just for the laughs. Good luck out there =)
  - tialaramex 2y ago
    For WUFFS the language, or for WUFFS the library, or for the WUFFS tooling today? The clever idea is to have you the programmer in effect write a proof that your code has the desired semantic properties as part of the programming activity and so then the WUFFS transpiler is merely checking that the proof is correct. This leverages your understanding of what you were trying to do.
    - immibis 2y ago
      Apparently Wuffs only proves safety. Verifying the code does what it's supposed to do is done with unit tests.
- lupire 2y ago
  WUFFS is provably safe, or WUFFS programs are provably safe, using WUFFS as an axiom?

tialaramex 2y ago

I worked with TIFF pretty extensively, it's a mess but I don't see why a WUFFS TIFF codec can't be fine. What makes you say you need "an actual VM to transcode" a TIFF ?

Joel_Mckay 2y ago
The complex formats of tiff and tga specifications makes it nearly impossible to span all the edge-cases with unit-tests. A VM can be in a known-state snapshot, process pre/post signature logged/compared with a scripted debugger, and binary input/output stripped of non-compliant metadata/blobs at each stage of the pipeline if the process behaves as expected. I've yet to find a better method than Honeypots to sustainably mitigate the complex leaky dependency mess on traditional architectures. It has been my experience that "all software is terrible, but some of it is useful". It may just be my bias, but I see code smell getting worse in recent decades... Have a nice day, =3 https://www.youtube.com/watch?v=aCbfMkh940Q https://www.youtube.com/watch?v=aCbfMkh940Q
- tialaramex 2y ago
  So, there's actually no particular reason and if somebody cares to write one then yup, TIFF codec in WUFFS would in fact be safer and faster than your uh, approach.
  - Joel_Mckay 2y ago
    One does not rely on the persistent competence of the coders, and will tell you when something has gone wrong. And walking a binary object store to ban problem users is not always necessary... depending what you are doing. Most other approaches makes the same predictable assumptions: https://en.wikipedia.org/wiki/List_of_cognitive_biases https://en.wikipedia.org/wiki/List_of_cognitive_biases Despite popular belief, shitty design does not usually get better in another language. Rather, people just feel more confident it isn't shit anymore. I have yet to see evidence to the contrary. =3
    - tialaramex 2y ago
      Wait, you believe that somehow one of these approaches doesn't rely on competence from programmers? How do you figure? Have you been imagining that sandboxes are some sort of fairy dust we just stumbled onto one day, supernatural in nature and not, in fact, just software written by people you're hoping are competent and haven't left any holes?
      - Joel_Mckay 2y ago
        The point was... one is testing parser/OS integrity via a debugging interface over an expectation of an unchanging emulated environment state... there is nothing particularly special about the approach. Even Qubes OS and RancherVM is not perfect in this regard friend. Or put another way, the available attack surface of a bare-minimum fixed environment is much easier to auto-audit, than a pile of daily permuted binaries and self-delusion approach. i.e. if it fails to behave in an expected way, or is modified in any way... the host audit process doesn't have to care why or how it is broken to maintain a service queue as the guest is culled. Perhaps I am wrong about exchanging 15% of raw performance for reliability, but things can get complicated with licenses and multiple OS specific platforms. You seem to be getting emotional about this subject, presenting secondary and tertiary straw-man arguments. So I'm going to go eat some Cheese Goldfish crackers... and just agree that your beliefs are interesting. Have a fantastic weekend... =3
        2y ago

immibis 2y ago

WUFFS is provably safe - that's the whole schtick. If a WUFFS kernel exists, you can assume it is safe. If it's not proven safe, it doesn't compile. The reason everyone doesn't program in WUFFS is that you have to write a proof that your kernel is safe, which takes a very very very long time.

deleted 2y ago
[deleted]
indolering 2y ago
What's the formal verification story for WUFFS?
- Joel_Mckay 2y ago
  If you point out some of the above has run-state in some situations... it is provably nondeterministic... and thus the assertion of correctness is utter nonsense. Hardly a panacea for fundamentally bad designs that go back decades. Ever seen a web-server written in postscript? Its worth a look just for the laughs. Good luck out there =)
- tialaramex 2y ago
  For WUFFS the language, or for WUFFS the library, or for the WUFFS tooling today? The clever idea is to have you the programmer in effect write a proof that your code has the desired semantic properties as part of the programming activity and so then the WUFFS transpiler is merely checking that the proof is correct. This leverages your understanding of what you were trying to do.
  - immibis 2y ago
    Apparently Wuffs only proves safety. Verifying the code does what it's supposed to do is done with unit tests.
lupire 2y ago
WUFFS is provably safe, or WUFFS programs are provably safe, using WUFFS as an axiom?