Hi Klaus,
You can't check a revision without resynchronizing it. If you suspect you might have infected revisions, I would expect that all the revisions would be checked by either the Integrity Administrator, the Security team, or someone on the Development team by resynchronizing all the versions. Source Integrity is there to manage the versioning, regardless of what's in there. The need to make sure that what's in there is the right thing is outside of Integrity's scope.
To be properly security conscious, it would probably be best to sandbox and script the scanning of suspected revisions by:
- Create a fire-walled virtual machine to do the scanning, and to prevent an accidentally activated infection from being able to propagate through the network
- Creating the sandboxes from the command line in one directory structure
- Scanning the lot of them with one scan action without ever putting them in a situation in which they can be executed (so never context-menu click on any of the potentially infected members, never put them in the executable path variable for the operating system and so on)
- If possible, scripting the deletion of the problem revisions based on the output of the virus scanner
- Delete/rollback the virtual machine to a known good state
If you wanted to be as defensive as possible, you could do a post-checkout scan. This isn't recommended because:
- It would slow down all affected checkouts substantially
- You'd have to write a trigger script to call the virus scanner on a member-by-member basis against the member
You might be tempted to simply scan every member as it's being checked in (or even just members with certain extensions). This slows down check-in for all the affected members (assuming you restrict it to members known to carry virus payloads, this could still be substantial). If you filter by extension, "clever" users will add .txt or .jpg to some member names before checking them in to speed up the check-in process, defeating the automatic scan.
The real solution is to minimize the possibility of getting an infected member in the first place, which can be difficult. A worst case example would be something along the lines of a requirement for a particular open source executable for a given project, but the official site of that software package is compromised, you'll have to build from source to get a clean version, and you'll have to review the source first.
Regards,
Kael
Kind Regards,
Kael Lizak
Senior Technical Support Engineer
PTC Integrity Lifecycle Manager
