MaxRequestBodySize and MultipartBodyLengthLimit issues.

[JoKneeMo]

I'm having an issue with large files being uploaded but I do not have the C# experience to resolve this issue myself.

Originally, I couldn't sign files larger than 30MB. I would get the following error.
[ERR] An unhandled exception has occurred: Request body too large.

I was able to resolve this by adding the below to line 38 of src/SecureSign.Web/Program.cs
options.Limits.MaxRequestBodySize = null;

However, now I am getting the error
[ERR] An unhandled exception has occurred: Multipart body length limit 134217728 exceeded.

I've tried setting the MultipartBodyLengthLimit as referenced here but is not a valid namespace and I can't seem to figure out what's missing to increase this limit.

For reference, I'm signing a 1.1GB exe package.

[Daniel15]

It looks like that FormOptions class is in the Microsoft.AspNetCore.Http.Features namespace, so if you add this to the top of the file, it should work!

using Microsoft.AspNetCore.Http.Features;

Let me know how you go... I haven't tried with such large files :)

[Daniel15]

Note that you'll need to add that to the Startup class, not Program, around here: https://github.com/Daniel15/SecureSign/blob/master/src/SecureSign.Web/Startup.cs#L33

[JoKneeMo]

Thanks!!!

Adding that class did the trick.

Afterwards, I was able to sign much larger packages but the allocated RAM was only 2GB.
This caused messages regarding memory allocation for the file being signed.

I bumped the RAM up to 8GB and had to increase the timeout in AuthenticodeSigner.cs higher than 10s.

I found out that the RAM needed for this server is 4x the size of the largest package you would be signing. If signing a 1.5GB exe, you need at least 6GB of free RAM when the SecureSign service starts. I was expecting it to only need 2x but that was not the case.

It DOES seem to hold the memory after signing that package, but subsequent ones of that size seem to process fine.

[Daniel15]

It DOES seem to hold the memory after signing that package

C# is garbage collected so it's likely the memory usage would drop a lot when the garbage collector runs. It's possible SecureSign could be optimized a bit more to reduce memory allocations; so far I haven't done any optimizations at all as I'm only using it for small files (few MB).

[Daniel15]

Currently the input is stored as a byte array in memory, and data is returned as a byte array. Changing the returned data to a stream should improve things a bit, as then the response could stream from a temp file on the hard drive instead of buffering the entire thing in RAM.

I filed #8 to look into that. I'm going on vacation next week and probably won't get a chance to look into it before then though.

[Daniel15]

@JoKneeMo Can you please try the latest master branch? I just pushed some changes that should improve this quite a bit, by using streams and buffering on disk instead of buffering the entire file in RAM. I tested with a 500 MB file and memory usage remained flat. I also made the changes you had to make to get large files working (increased a few limits)

[Daniel15]

@JoKneeMo - Were you able to try the latest version and see if it works well for you?

[JoKneeMo]

@Daniel15 I realize you have closed this issue, but I wanted to let you know that I encountered this problem again when signing a package larger than 2GB. Nothing I was doing would fix the issue, however, your update did! Thanks!

After merging your changes into mine, I was still unable to get it to work immediately.
The fix was actually the first local modification that I made to the original version, it was to remove the SHA1 nested signing function. I'm not sure how this works for anyone with that there, but removing it fixed it for me. My other modifications are not related to the actual asp, so I don't think it was anything I was doing.