Given the dynamic nature of BOINC projects, i.e., multiple clients that may be viable depending on the science that is being conducted for any arbitrary project's WUs, it would facilitate things for project participants that utilize firewalls, HIPS applications such as Comodo Internet Security, if project developers would digitally sign their binaries with a certificate from a trusted CA.

http://internetsecurity.comodo.com/trustedvendor/signup.php

The above URL is a link to a form that allows software vendors to request the addition of their software to the Trusted Vendor List that ships with Comodo Internet Security. This ensures their software will be automatically trusted by the application.

•Your software must be available for download by [Comodo] technicians
•Your software must be code signed with a certificate from a trusted CA (self-signed code signing certs are not acceptable)
•The 'Company Name' you provide below matches the name of the signer on the certificate
•You must provide a valid email address

Please forward this request to adminstrators of all BOINC projects w/the request that ALL of their project applications be digitally signed, e.g., Lattice which has no less than three distinct distributed computing applications avail.

Please forward this request to adminstrators of all BOINC projects w/the request that ALL of their project applications be digitally signed, e.g., Lattice which has no less than three distinct distributed computing applications avail.

Science applications running under BOINC are digitally signed. Buying a code-signing certificate costs money, a few hundred a year, most projects cannot afford the expense. Therefore BOINC uses the projects self-generated code-signing certificate (which is free), or projects can choose to use a regular code-signing certificate.

See [trac]wiki:CodeSigning[/trac] and [trac]wiki:CertSig[/trac] for more information.

---

I appreciate your response. I understand the concern about the cost of trusted CA certification. As it stands, BOINC manager and core client are selectable w/in Comodo Internet Security Defense+ Trusted Vendor screen on the baxis that the code is at a minimum self-signed as @University of California, Berkeley (company name: Space Sciences Laboratory). This, at a minimum, allows BOINC to be defined as user trusted by the user.

Unfortunately NONE of the binaries for projaects I particpate in are signed and therefor not selectable as being trusted vendors. Unfortunately, as a result of this, when Comdodo encounters the executable of any arbitrary project for the first time, it is ssandboxed as an unrecognized application. The virtualization that sandboxing entails results in the abortion of that WU. Although the project application can be configured trusted, release of another project application core will result in the same ocenario, e.g.

minirosetta_2.15_windows_intelx86.exe
minirosetta_2.14_windows_intelx86.exe

...\projects\boinc.gorlaeus.nettrajtou-pd110paw_5.40_windows_intelx86.exe
...\projects\boinc.gorlaeus.net\classical_5.56_windows_intelx86.exe

Moroever, although ...\projects\boinc.bio.wzw.tum.de_boincsimap\simap_5.10_windows_intelx86.exe has GSF specified for company name in the exe's properties, it is not digitally signed. In fact, BOINCSimap is the only BOINC project app with such declaration.

Its disappointing to realize that neither BOINC nor associated project applications could ever be on the Comodo Trusted Vendor list. I understand that this is just an economic fact of life. However, if you could bring to bear whatever influence you may have with any arbitrary project themselves, if they at a very minimum self-sign their binaries, that alone would facilitate things for CIS users.

Thank you for your consideration and attention to this matter.

Its disappointing to realize that neither BOINC nor associated project applications could ever be on the Comodo Trusted Vendor list. I understand that this is just an economic fact of life. However, if you could bring to bear whatever influence you may have with any arbitrary project themselves, if they at a very minimum self-sign their binaries, that alone would facilitate things for CIS users.

To be honest, I have a big desire to troll but I stay off. However, I beg to bring to your attention another sad fact: boinc isn't your personal army. You should understand, that whoever would ask for such signing would be requested, in turn, to bring funds with at once. And that's not going to go.

However, I can provide you with a bit of hope. Eventually, Comodo will go and take this problem with it.

---

I'm counting for science,
points just make me sick.

Unfortunately NONE of the binaries for projaects I particpate in are signed

Sorry, but you're wrong. Want to see if they're signed or not? Check in client_state.xml

E.g. on Rosetta, Project key:

<code_sign_key>
1024
da94985671f399f2ccbb8711004a4d7b782f239babc54e4db341dd1c7b94fbf3
745d30084d332667546f400f5063e683c812a69a5d0945f53f0421961337e3f0
cfad19652eb4f50523473f92ee3b1f43d358a5ba911479e553f43c91b8a4939a
6aa5258107ef609a240bcffcfc9a19c8a8b0df99fdb9508694d499478fb0a931
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000010001
.
</code_sign_key>

Application key:

<app>
    <name>minirosetta</name>
    <user_friendly_name>Rosetta Mini</user_friendly_name>
</app>
<file_info>
    <name>minirosetta_graphics_1.92_windows_x86_64.exe</name>
    <nbytes>5345280.000000</nbytes>
    <max_nbytes>0.000000</max_nbytes>
    <status>1</status>
    <executable/>
    <signature_required/>
    <file_signature>
b6df67ce33f8e95fcb988d8a4f76cc10dd1f82766d81db084526de6132e8969f
3f68c300d9b706ebc21eebea9f90b15319078e0a317b698f9dcb9a291b6a5884
4d2ba3c1825a1a9a87a892e0d1a39e20450ddfe714244d066b08468bb22dc494
21c6b9e127361a347545831fd311f6fa9dba5623a7c370522290e0c9dc322ae9
.
</file_signature>

<file_info>
    <name>minirosetta_2.15_windows_x86_64.exe</name>
    <nbytes>12480512.000000</nbytes>
    <max_nbytes>0.000000</max_nbytes>
    <status>1</status>
    <executable/>
    <signature_required/>
    <file_signature>
aa3d02fed2fd70cb4f41b345bf731d1cfac9fef8312931d00b8312bcac412ea8
600ea1851f43a73ad787b0e605ac35741fda571f85ff72c1a231cc6bfd766f7a
4b78e0da412537ca71e66d19f5470f6e2d395f168d6f186c5e70316c2870a574
e4606b09c3d8c9f2402931d5a3dc0dd03caf011027eae6ccf67357ed8fda1b7d
.
</file_signature>

Those file signatures you see there are the public keys that the project signed their project and applications with.

Each newer application comes with its own newer key.

When your AV wants to be intrusive, exclude your BOINC Data directory and all its sub-directories from being (actively) scanned by the AV. Only scan them by hand when BOINC is closed down.

---

Thanks for the reply Ageless. Apparently there's a distinction between public keys and digital signatures.

BOINC.exe properties has a tab that displays a digital signature. That tab is missing for all project apps. Maybe UoC, Berkeley sprung for the cost of BOINC CA certificate? If that's the case, then the public keys of the project apps is a moot point in that they're not valid for establishment of 'trusted' application by HIPS computer security applications.

The issue isn't that of AV in that the apps aren't being detected as malware. What's occuring is the apps are being detected as 'unrecognized' and virtualized in sandbox. THAT results in WU computation error until the project app is manually declared 'safe' by the user. How long it takes for computation error to manifest itself is as long as it takes for the project app to attempt access of some system resource, e.g., run executable, interprocess memory access, Windows / WinEvent hooks, process termination, Windows Messaging, protected COM interfaces, protected registry keys, protected files / folders, DNS / RPC client service(s), physical memory, monitor, disk or keyboard.

The foregoiong are intercepted by Comodo's HIPS on a per application basis. That means that minirosetta_2.14_windows_intelx86.exe has a suite of access rights. When minirosetta_2.15_windows_intelx86.exe was released, that executable needed an entirely discrete set of access rights.

BOINC.exe has a dgital signature and can be user defined as trusted. There's no problem with BOINC's access rights. It has rights to run anything in BOINC_data\projects. So BOINC.exe launching
...\projects\boinc.gorlaeus.nettrajtou-pd110paw_5.40_windows_intelx86.exe
is not an issue. But ...\projects\boinc.gorlaeus.net\trajtou-pd110paw_5.40_windows_intelx86.exe launching
...\projects\boinc.gorlaeus.net\classical_5.56_windows_intelx86.exe IS an issue. And furthermore, whatever
...\projects\boinc.gorlaeus.net\classical_5.56_windows_intelx86.exe wants to do will ALSO be an issue.

Obviously one solution would be to declare EVERY file contained in ...\projects\* & ...\slots\* as trusted. But what kind of maintenance nightmare is that when projects update their apps (as per minirosetta_2.14 & minirosetta_2.15 for example)?

One solution to this would be to have all the projects apps digitally signed akin to the way the BOINC client / manager are. However, as you explain, that doesn't seem to be feasible. However, you did mention that BOINC uses the project apps public keys as a verification mechanism internal to BOINC to determine the integrity of the client apps being run by BOINC. I'm certain the problem could be resolved if the Comodo HIPS client was similiarly aware of these project application public keys. But as it stands, that's not possible without communication between BOINC devs and Comodo devs.

After some investigation into this matter, I determined this isn't all that much of an issue. While it may be ideal to have BOINC and any BOINC projects recognized by Comodo Internet Security suite out-of-the-box as trusted applications, if the BOINC projects & slots folders are desigated with 'installer / updateer' HIPS policy, sandboxing of any BOINC project binaries is circumvented.