| 6 May 2025 |
 GGG | I wonder what's the likelyhood of c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2 appearing in a normal binary | 13:49:39 |
| GGG | maybe as a set of bytes it could happen, but as a sequence of ASCII characters I'm not sure | 13:49:51 |
 Corngood | I think that would depend on where it came from. Maybe I can track that down. | 13:50:32 |
| Corngood | If it's guid-ish then ~0 | 13:50:46 |
| GGG | I'm doing a simple preliminary test by doing grep -sRl 'c3ab8ff13720e8ad9047dd39466b3c89' /nix/store | 13:50:55 |
| GGG | it seems like they just SHA-256'd "foobar" | 13:51:13 |
| GGG | according to the comment on the code you posted | 13:51:19 |
| Corngood | oh, lol. that was stupid of them | 13:51:29 |
| Corngood | it's probably fine, but they could have easily avoided the possibility of someone else doing the same thing | 13:51:59 |
| Corngood | still, they were only concerned about their codebase and dependencies | 13:52:28 |
| Corngood | we don't need to differentiate already-patched or source-built binaries, do we? | 13:53:39 |
| GGG | no, this was only so I could make a hook to do the patching we do for pre-built .NET apps | 13:54:13 |
| GGG | that adds the whole ICU, Kerberos, OpenSSL and etc. deps | 13:54:25 |
| Corngood | But I mean we're not mixing other stuff in the same outputs that are being patched? | 13:56:10 |
| GGG | even if we do, there shouldn't be any harm I think | 13:56:36 |
| Corngood | I'm just thinking about if we make a general hook for doing this. We might want to warn against using it on already patched things.
Like you said it probably wouldn't break anything. Patched runtime would still explicitly load libs from /nix/store. | 13:57:17 |
| GGG | yeah, looking at the actual effects of it, it'd only add a few unnecessary RPATH and needed entries | 13:57:53 |
| GGG | but it wouldn't result in anything more in the nix store nor unnecessary packages being pulled in | 13:58:07 |
| GGG | if it's a framework-dependent apphost, then the runtime in the nix store should already work, so perhaps we only need to identify self-contained apphosts? | 13:58:58 |
| Corngood | Other than apphost and singlefilehost, is there anything else we need to worry about? Do they ship AOT things? | 13:59:13 |
| Corngood |
self-contained apphosts
This would be singlefilehost I believe. Let me see what one of those looks like after build.
| 14:00:07 |
| GGG | AOT would indeed be an issue we need to worry about as well, I don't know how the AOT binaries are built, I'd need to check to see if they have ICU among the needed libraries | 14:00:06 |
| Corngood | I sort of doubt they would have that magic foobar hash in them. | 14:00:35 |
| GGG | let me check with patchcil | 14:01:01 |
| GGG | it's the only AOT program we have in nixpkgs afaik | 14:01:09 |
| Corngood | But are they statically or dynamically linked against the ssl shim? | 14:01:09 |
| GGG | it should be static, since it's a self-contained binary | 14:01:34 |
| GGG | it should only need the external deps, no runtime nor anything else | 14:01:42 |
| Corngood | so AOT is always a single file? | 14:01:55 |
| GGG | it has some auxliary files like the pdb and other native dlls (when nuget libraries use pinvoke), but I haven't seen AOT binaries with dlls | 14:02:40 |
