Prevent unpacking of possibly spoofed backups (as a last line of defence if other security has failed).
Zips with partially known content are a lot harder to spoof.
Thanks WhiteHats :-)
It's mostly a theoretical problem, but 16 could theoretically be brute
forced. Bumping it up to 32 won't break anything, but it does make it
exteremely unlikely that it gets broken
Now that we subscribe for all situations where a package is installed,
it makes sense to watch package installs and create a 1:1 relation that
way. Prevents code duplication.
CURA-7099
If it's not used that way we want to know about it and fail.
If plug-ins use it this way, the plug-in won't get initialised so it'll be as if the plug-in is disabled or that function doesn't work.
Contributes to issue CURA-7135.
The setting print_sequence was not being resetted to all at once
whenever the 2nd extruder was reactivated.
This commit fixes that by explicitly resetting print_sequence
when reenabling an extruder, if it has been changed by the user.
CURA-6914
It could happen that the selection pass is not initialised because you're right clicking on the screen before the first render has happened.
Hopefully this fixes#6976.
The container registry was incorrectly being searched with a
variant_name == None, which always returned an empty printer-specific
materials list. As a result, the generic material settings were always
being loaded if there was no variant specifically indicated inside
the fdm_material file. The printer specific values were consistently
being ignored.
This commit fixes that by removing the search with a variant_name==None
which correctly returns the printer-specific materials list while
loading the materials from the variant nodes.
CURA-7087
Only whenever the sentry_sdk module is there functions of this module will be used.
The only changes, which were needed to be made, are done on cura_app.py and cura.CrashHandler.
Whenever the module is not available, it's functions will be omitted.
The if-clauses could happen earlier, but this at least the bare minimum, and, to be honest, on Ultimaker's distribution it won't speed up anything.
I expect the if-clause to take the same amount of runtime sooner or later. The check is the same and it should be on Ultimaker's distribution always be "True".
Signed-off-by: Thomas Karl Pietrowski <thopiekar@gmail.com> (github: thopiekar)
Change the order of initialization, so the MachineErrorChecker already has its signals attached when the first machine gets loaded.
The increased number of 'processEvents'-calls exposed this oversight by allowing it to run out of order.
(MachineErrorChecker initializes the has-errors field to True if no check has been done yet.)
The PrintInformation test wasn't cleaning up after itself correclty. This
left some stuff behind that the other tests were using. Since this is bad (as at that point
tests can influence other tests), i've fixed that
