PaperCut NG/MF 22.1.1 upgrade checklist

Depending on the features you’re using in PaperCut MF/NG, some functionality could potentially stop working if you’re upgrading from a PaperCut MF/NG version earlier than 22.1.1, to 22.1.1 or later. If you have already upgraded to 22.1.1 or later, and you’re looking to upgrade to an even later version, you don’t need to use this checklist again.

Use this checklist to see if there are any actions required after upgrading.

Summary checklist

Feature in use	Action required?
Print Scripting or Device Scripting	NO 1
Print Scripting with extended Java classes	YES
Device Scripting with extended Java classes	YES
Custom card number conversion scripts	NO 2
Custom card number conversion scripts with extended Java classes	YES
Custom user authentication and user sync program	YES
Domain user or service account in use for the PaperCut Application Server service or PaperCut Print Provider service	NO 3

1   Consider reviewing this configuration based on your organization’s functionality and security needs. See Are you using Print Scripting or Device Scripting? below.

2   Consider reviewing this configuration based on your organization’s functionality and security needs - e.g. narrow down the allowed paths for custom scripts. See Are you using a custom card number conversion script? below.

3   Consider reviewing and potentially changing the permissions on the security.properties file. See Are you running any PaperCut services as a domain user account or service account? below.

Are you using Print Scripting or Device Scripting?

• I’m not sure: To find out, see the FAQ How do I know if I’m using print or device scripts? below.

• No: No action is required. However, if you choose to disable it, set the new security.properties file key security.print-and-device-script.enabled to N. See Disabling Print Scripting and Device Scripting for information on how to do this.

• Yes: No action required - the new security.properties file key security.print-and-device-script.enabled is set to Y on upgrades, so print and device scripting will continue to work.

Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes.

Note: The ‘old’ config key (print-and-device.script.enabled) in the admin interface config editor will remain listed, but will no longer have any impact on functionality.

Are you using Print Scripting with extended Java classes?

• I’m not sure: To find out, see the FAQ How do I know if I’m using extended Java classes in scripting? below.

• No: No action required - for upgrades and new installations, the new security.properties file key security.print-script.allow-unsafe-code is set to N (the most secure option).

• Yes: Action required - if you choose to continue to use extended Java classes in Print Scripts, set the new security.properties file key security.print-script.allow-unsafe-code to Y. See Using extended Java classes in scripts for information on how to do this.

Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes.

Note: The ‘old’ config key (print.script.sandboxed) in the admin interface config editor will remain listed, but that key will no longer have any impact on functionality.

Are you using Device Scripting with extended Java classes?

• I’m not sure: To find out, see the FAQ How do I know if I’m using extended Java classes in scripting? below.

• No: No action required - for upgrades and new installations, the new security.properties file key security.device-script.allow-unsafe-code is set to N (the most secure option).

• Yes: Action required - to continue to use extended Java classes in Device Scripts, set the new security.properties file key security.device-script.allow-unsafe-code to Y. See Using extended Java classes in scripts for information on how to do this.

Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes.

Note: The ‘old’ config key (device.script.sandboxed) in the admin interface config editor will remain listed, but that key will no longer have any impact on functionality.

Are you using a custom card number conversion script?

• I’m not sure: To find out, see the FAQ How do I know if I’m using a custom card number conversion script? below.

• No: No action required. However, if you choose to disable custom conversion scripts completely, remove the * option from the new security.properties file key security.card-no-converter-script.path-allow-list. See Disabling card converter scripts for information on how to do this.

• Yes: No action is required unless you use extended Java classes. However, if you choose to allow a particular script, update the security.properties file key security.card-no-converter-script.path-allow-list to specify the exact card number conversion script path in use (by default this is set to *). In addition, if your card conversion script is using extended Java classes, you can choose to set the security.properties file key security.card-no-converter-script.allow-unsafe-code to Y. See Enabling card converter scripts (and optionally Using extended Java classes in scripts) for information on how to do this.

Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes.

Are you using a custom user auth or sync program?

• I’m not sure: To find out, see the FAQ How do I know if I’m using a custom user auth or sync program? below.

• No: No action required.

• Yes: Action required - if you choose to continue using your custom auth/sync program, specify the custom program paths in the security.properties file key security.security.custom-executable.allowed-directory-list. See Synchronizing and authenticating user and group details with custom programs (executables) for information on how to do this.

Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes.

Are you running any PaperCut services as a domain user account or service account?

• I’m not sure: To find out, see the FAQ How do I know if I’m using a domain user account or service account? below.

• No: No action required.

• Yes: No action is required. However, if you choose to continue running the PaperCut Application Server service or PaperCut Print Provider service with a domain user account or service account, you can set the file permissions so that the service does not have edit access to the [app-server]\server\security.properties file.

  Permissions for the security.properties file:

  • PaperCut Application Server Service account - allow read access, deny write access
  • PaperCut Print Provider Service account - deny write access (read access is not required but it’s ok if the service account has read access)

  This is to ensure that the service accounts cannot make changes to the security.properties file - only an organization’s Administrator should be able to edit that file manually.

FAQs

No. This only impacts your configuration for the specific functionality of PaperCut MF/NG mentioned above.

You do not have to make any changes to any other components (including Print Deploy, Mobility Print, Multiverse, User clients, and device embedded software).

Check the following locations to see if you have checked the Enable print script or Enable device script box for any of your printers or devices, to tell if you are using print scripting or device scripting in your environment:

• Printers > [select printer] > Scripting > Enable print script
• Devices > [select device] > Scripting > Enable device script

If no scripts are enabled, then you’re not using print or device scripting.

In the Admin interface, go to Options > Actions > Config editor (Advanced).

Find the config key ext-device.card-no-converter and check if it’s been configured with a converter value.

• If it has, you’re using a custom card number conversion script.
• If the value is blank, you’re not using a custom card number conversion script.

In the Admin interface, go to Options > User/Group Sync > Sync Source > Primary Sync source.

Check to see if the Primary Source has been set to Custom Program.

• If it has, then you’re using the custom user auth or sync programs defined in the two text boxes below that.
• If the primary sync source is set to anything else (for example Azure AD, Google Cloud Directory, LDAP etc) then you’re not using a custom program.

To understand if you’re using extended classes, generally if you are using classes outside of dates, numbers, and strings (those listed on the Print script API reference or Device script API reference) then you may be using extended classes. These may include calling OS-level commands or accessing non-type classes from your print or device script.

Generally this is rare. This functionality has also been disabled by default, in any version released since June 2022, including 19.2.7, 20.1.6, 21.2.10 and 22.0.0 or later.

For more information see Using extended Java classes in scripts.

Review the section How to set up PaperCut to run as a different account to see if you’ve set up your PaperCut Application Server or PaperCut Print Provider services to run as / login as a domain user account or some other service account.

If you’ve configured one of those services to login as e.g. ‘papercut-service’ or some other service account which isn’t the default SYSTEM account, then you’re using a domain user account or service account.

Yes - see the table below for a summary of old config keys, and new security.properties file keys. It’s also included in the Secure configuration of high-risk features in PaperCut NG/MF page in the manual.

Note: Any changes to the new security.properties file need an Application Server service restart to pick up the changes.

Config editor key (Options > Actions > Config editor)	security.properties file key [server install]/server/security.properties	New security.properties file defaults in 22.1.1
print-and-device.script.enabled 1	security.print-and-device-script.enabled	Y - on upgrade N - new installations
print.script.sandboxed 1	security.print-script.allow-unsafe-code	N - on upgrade N - new installations
device.script.sandboxed 1	security.device-script.allow-unsafe-code	N - on upgrade N - new installations
N/A	security.custom-executable.allowed-directory-list 2	(blank/empty) - on upgrade (blank/empty) - new installations
N/A	security.card-no-converter-script.path-allow-list 3	* - on upgrade (blank/empty) - new installations
N/A	security.card-no-converter-script.allow-unsafe-code 3	N - on upgrade N - new installations

1   These config editor keys remain in the admin interface config editor, but have no function in version 22.1.1 or later.

2   This key is used in conjunction with the Custom user and Custom auth programs. These are set in the Admin interface: Options > User/Group Sync > Sync Source > Primary Sync source > Custom program, then setting the Custom user program and Custom auth program fields.

3   These keys rely on a custom card number converter being defined in the config editor config key ext-device.card-no-converter. You also have to enable card converter scripts.

The security hardening features in this release are focussed on reducing the attack surface for potential future vulnerabilities - in short, limiting the tools that potential hackers have at their disposal.

For example if you don’t use print scripting at all, we recommend disabling it as above - since that limits the attack surface further. We recommend organizations consider reviewing and potentially changing this configuration based on their functionality and security needs.

As always, we recommend following your security best practices, running anti-malware and endpoint security software as appropriate.

We understand that many of our customers use print scripting for enhanced functionality - everything from charging, access, routing and much more. For those customers, disabling print scripting could have an immediate impact on end-users ability to print.

If you’re not using print and device scripting or custom card number conversion scripts (see the table above), we recommend organizations consider reviewing and potentially changing this configuration based on their functionality and security needs.

Ok, but why didn’t you just see if I was using scripting, and then set the new security.properties key accordingly?

By design, the PaperCut Application Server service should not have access to update the new security.properties file. Because of this the installer (run by an Administrator) creates the new file and sets the configuration. At the point that the installer runs, we don’t have access to the PaperCut database, and are unable to see what the ‘current’ environment is set up with.

Because of this deliberate permissions restriction, we had to go with a set of defaults appropriate for all customers, and then allow customers to change their security settings as appropriate for their environment, post-install / post-upgrade.

We have also included a PaperCut MF/NG admin interface alert for administrators, which will alert them to any changes made in their configuration on upgrade.

Yes! If you prefer to keep things tidy, you can delete the old config keys that are no longer in use after upgrading to 22.1.1. We have kept these keys by default so that you can refer to them historically, but they are no longer required or used.

They can be found in the config editor in the PaperCut MF or NG admin interface > Options > Actions > Config editor then searching for the relevant key:

• print-and-device.script.enabled
• print.script.sandboxed
• device.script.sandboxed