I'd like to enable users of my service to write and execute CodeQL queries. I don't want to offload their execution to GitHub's / Semmle's servers. It's unclear whether this is doable, or whether I'd run into licensing issues.
In the security lab, it says "CodeQL is free for research and open source". I do want for the queries––which users write––to be open source. I don't, however, want for their execution to done by an external service.
Any thoughts would be greatly appreciated. Thank you!
The full CodeQL license terms are available here. The license states (emphasis added):
Further, except (and only to the extent) permitted by applicable law or applicable third-party license, you will not (and have no right to):
... share, publish, distribute or lend the Software, provide or make available the Software as a hosted solution (whether on a standalone basis or combined, incorporated or integrated with other software or services) for others to use, or transfer the Software or these Terms to any third party.
What you are considering is explicitly disallowed by the license.
If you'd like to explore options, I'd suggest reaching out to the GitHub Security Lab directly.
I originally posted this question as an 'answer' to:
Can a single company really not use QB API?...Semi Rant
but am reposting, because it is a question.
The original poster and I face a similar problem wanting to use the QBO API for an application designed for a single company. What would be the disadvantage of connecting my app to my QBO account using the intuit development server indefinitely, i.e., never take my app through the production qualification process?
Thank you.
I believe that is possible but then you can use at max 10 developer connections.
As we already mentioned we do not not support custom integrations at this time.
Even we wouldn’t recommend moving you to production as it would cost us $1k per year to security review it, and we would only recover about $60 per year in connection fees.
So, the disadvantage for you will be in terms of number of connections, limited support and your app vulnerability since it has not gone through the security review process.
Please read the policy docs mentioned here:
https://developer.intuit.com/docs/0025_quickbooksapi/0005_introduction_to_quickbooksapi/z_developer_policies_and_guidelines
Edit for the question asked:
When you login into developer.intuit.com, Go to Manage My Apps, then click your app.
You will see the number of connections for that app under Test connections.
It refers to the numbers of company files your app is associated with or has been authorized to access data.
We have a code-signing certificate, purchased from GlobalSign for Authenticode signing (as they call it). Now we need to sign Java applet and soon Adobe AIR module (applet?). The question is: from technical point of view is there any difference between certificate-for-Authenticode and certificate-for-Java or certificate-for-AIR, if they are issued by the same CA (say Comodo or GlobalSign)? I don't see a point in buying different certificates if they are replaceable.
I understand that key usage field of certificates must be the same (code signing), but maybe extended code usage or policy or other extension differs in those certificates. I would appreciate if somebody who has code-signing certificates of two or more types issued by one CA could check this for me.
There's an explicit statement at http://www.adobe.com/devnet/air/articles/signing_air_applications.html that:
"A developer can use any class-3,
high-assurance certificate provided by
any CA to sign an Adobe AIR
application."
Unfortunately, I can't find anything similar for Java. However, regardless of the minimum certificate requirements for the various platforms, your best bet might be to contact your existing certificate provider to ask if there are any meaningful differences between the certificates they offer for these platforms.
Some of the blah-blah on the Verisign website suggests that the format in which the certificate is delivered to the purchaser is the only real difference between their offerings, but they don't actually state this directly, so who knows...?
From what I gather from RFC 5280, the key usage extensions can only decide whether the certificate is usable for code signing or not. There doesn't seem to be anything in the RFC that can constrain whether you sign Java code or AIR or whatever. This seems to imply that if you can sign one piece of code (or any other kind of non-key data) you can sign any.
That said, there may be CA-specific extensions in your certificate. Without seeing the certificate it's hard to tell if there are limitations.
From a technical perspective, as long as the client (i.e. the browser if we're talking about applets) recognises the CA and is happy with your combination of key usage and certificate type (DIGITAL_SIGNATURE and OBJECT_SIGNING) then you should be fine.
It seems that any code signing certificate will work for any mentioned platform. I asked GlobalSign support about the difference - they didn't respond, however soon after that they have changed their web page and now you would be buying one code signing certificate for all platforms.
we are developing an anti-virus, I'm trying to find out how can we tell the operating system -windows XP in this case- that our software is an anti-virus. I want that the OS recognize our software as an anti-virus and the security center list it.
You have to sign an NDA to get the information. Quoth MSDN forums:
To register an antivirus product:
Must be a member of the Microsoft
Virus Initiative.
OR
Must meet the following three
requirements:
Must have a standard NDA with Microsoft.
Must be a member of AVPD or a member of EICAR or must sign and
adhere to a code of ethics relating to
malware research and malware handling.
Must meet independent testing requirements:
a. If you are using your own antimalware engine, you must pass
VB100 and meet at least one of the
following:
ICSA Labs - Pass
West Coast Labs - Pass
AV-Test.de – 90% or higher
AV-Comparitives – 90% or higher
b. If you are packaging an antimalware engine from another
company:
The company who developed the engine must meet the
above requirements.
In order to be able to register an AV product with Windows Security Center, you need a private API from Microsoft or, starting with Windows 10 build 1809 you need to register a Protected Service. In order to do both these things, you need to be member in the MVI.
Just for the record, a few years later now, the requirements have changed a bit.
First of all, this is the new link:
https://learn.microsoft.com/en-us/windows/security/threat-protection/intelligence/virus-initiative-criteria
The criteria have also changed and they are more complex.
Assuming you have a product build with a 3rd party SDK, here are the requirements to become a member:
Offer an antimalware or antivirus product that is one of the following:
Your organization's own creation.
Developed by using an SDK (engine and other components) from another MVI Partner company and your organization adds a custom UI and/or other functionality.
Have your own malware research team unless you build a product based on an SDK.
3. Be active and have a positive reputation in the antimalware industry.
Activity can include participation in industry conferences or being reviewed in an industry standard report such as AV Comparatives, OPSWAT or Gartner.
Be willing to sign a non-disclosure agreement (NDA) with Microsoft.
Be willing to sign a program license agreement.
6. Be willing to adhere to program requirements for antimalware apps. These requirements define the behavior of antimalware apps necessary to ensure proper interaction with Windows.
7. Submit your app to Microsoft for periodic performance testing.
8. Certified through independent testing by at least one industry standard organization.
The most hard to achieve requirements are marked bold.
If you want more details what these things require, check here.
Best,
Sorin
I'm uploading a binary for the first time. iTunes Connect has asked me:
Export laws require that products containing encryption be properly authorized for export.
Failure to comply could result in severe penalties.
For further information, click here.
Does your product contain encryption?
I use https://, but only via NSURLConnection and UIWebView.
My reading of this is that my app doesn't "contain encryption," but I'm wondering if this is spelled out anywhere. "Severe penalties" doesn't sound pleasant at all, so "I think that's right" is a bit sketchy... an authoritative answer would be better.
Thanks.
UPDATE: Using HTTPS is now exempt from the ERN as of late September, 2016
https://stackoverflow.com/a/40919650/4976373
Unfortunately, I believe that your app "contains encryption" in terms of US BIS even if you just use HTTPS (if your app is not an exception included in question 2).
Quote from FAQ on iTunes Connect:
"How do I know if I can follow the Exporter Registration and Reporting (ERN) process?
If your app uses, accesses, implements or incorporates industry standard encryption algorithms for purposes other than those listed as exemptions under question 2, you need to submit for an ERN authorization. Examples of standard encryption are: AES, SSL, https. This authorization requires that you submit an annual report to two U.S. Government agencies with information about your app every January.
"
"2nd Question: Does your product qualify for any exemptions provided under category 5 part 2?
There are several exemptions available in US export regulations under Category 5 Part 2 (Information Security & Encryption regulations) for applications and software that use, access, implement or incorporate encryption.
All liabilities associated with misinterpretation of the export regulations or claiming exemption inaccurately are borne by owners and developers of the apps.
You can answer “YES” to the question if you meet any of the following criteria:
(i) if you determine that your app is not classified under Category 5, Part 2 of the EAR based on the guidance provided by BIS at encryption question. The Statement of Understanding for medical equipment in Supplement No. 3 to Part 774 of the EAR can be accessed at Electronic Code of Federal Regulations site. Please visit the Question #15 in the FAQ section of the encryption page for sample items BIS has listed that can claim Note 4 exemptions.
(ii) your app uses, accesses, implements or incorporates encryption for authentication only
(iii) your app uses, accesses, implements or incorporates encryption with key lengths not exceeding 56 bits symmetric, 512 bits asymmetric and/or 112 bit elliptic curve
(iv) your app is a mass market product with key lengths not exceeding 64 bits symmetric, or if no symmetric algorithms, not exceeding 768 bits asymmetric and/or 128 bits elliptic curve.
Please review Note 3 in Category 5 Part 2 to understand the criteria for mass market definition.
(v) your app is specially designed and limited for banking use or ‘money transactions.’ The term ‘money transactions’ includes the collection and settlement of fares or credit functions.
(vi) the source code of your app is “publicly available”, your app distributed at free of cost to general public, and you have met the notification requirements provided under 740.13.(e).
Please visit encryption web page in case you need further help in determining if your app qualifies for any exemptions.
If you believe that your app qualifies for an exemption, please answer “YES” to the question."
It's not hard to get approval for your app the proper way. SSL (HTTPS/TLS) is still encryption and unless you are using it just for authentication, then you should get the proper approval. I just received approval, and my app is in the store now for something that uses SSL to encrypt data traffic (not just authentication).
Here is a blog entry I made so that others can do this the proper way.
apple itunes export restrictions
Short answer: Yes, but you don't have to do anything
I was searching the web for this for some hours. Actually it is pretty easy and you can verify this in itunes connect:
1. All you have to do
If your app uses only HTTPS or uses encryption only for authentication, tokens, etc., there is nothing you have to do, just include
<key>ITSAppUsesNonExemptEncryption</key><false/>
in your Info.plist and you are done.
2. Verification
You can verify this in itunes connect.
select your app
chose features
chose encryption
click "+"
follow the dialog
for https or authentication the answer is yes and yes
In any case you should of course read yourself carefully through the dialog.
A very helpful article can be found here:
https://www.cocoanetics.com/2017/02/itunes-connect-encryption-info/
I asked Apple the very same question and got the answer (from a Sr. Export Compliance Specialist), that "sending information over https is forcing the data to go through a secure channel from SSL, therefore it falls under the U.S. Government requirement for a CCATS review and approval." Note that it doesn't matter that Apple has already done this for their SSL implementation, but for the government, if you USE encryption that is the same (to them) as you would've coded it yourself. I also updated our blog (http://blog.theanimail.com) since Tim linked to it with updates and details on the process. Hope that helps.
All of this can be very confusing for an app developer that's simply using TLS to connect to their own web servers. Because ATS (App Transport Security) is becoming more important and we are encouraged to convert everything to https - I think more developers are going to encounter this issue.
My app simply exchanges data between our server and the user using the https protocol. Seeing the words "USES ENCRYPTION" in the disclaimers is a bit scary so I gave the US government office a call at their office and spoke to a representative of the Bureau of Industry and Security (BIS) http://www.bis.doc.gov/index.php/about-bis/contact-bis.
The representative asked me about my app and since it passed the "primary function test" in that it had nothing to do with security/communications and simply uses https as a channel for connecting my customer data to our servers - it fell in the EAR99 category which means it's exempt from getting government permission (see https://www.bis.doc.gov/index.php/licensing/commerce-control-list-classification/export-control-classification-number-eccn)
I hope this helps other app developers.
If you use the Security framework or CommonCrypto libraries provided by Apple you do include crypto in your App and you have to answer yes - so simply because libraries were provided by Apple does not take you off the hook.
With regards to the original question, recent posts in the Apple Development Forums lead me to believe that you need to answer yes even if all you use is SSL.
As of September 20th, 2016, registering is no longer required for apps that use https (or perhaps other forms of encryption): https://web.archive.org/web/20170312060607/https://www.bis.doc.gov/index.php/informationsecurity2016-updates
In fact, on SNAP-R you can no longer choose 'encryption registration':
Specifically, they note:
Encryption Registrations no longer required – some of the information
from the registration now goes into the Supp. No. 8 to Part 742
report.
This means you may need to send an annual report to BIS, but you don't need to register and you can note when submitting your app that it is exempt.
Yes, according to iTunes Connect Export Compliance Information screens, if you use built-in iOS or MacOS encryption (keychain, https), you are using encryption for purposes of US Government Export regulations. Whether you qualify for an export compliance exemption depends on what your app does and how it uses this encryption. Attached images show the iTunes Connect Export Compliance Screens to help you determine your export reporting obligations. In particular, it states:
If you are making use of ATS or making a call to HTTPS please note that you are required to submit a year-end self classification report to the US government. Learn more
#hisnameisjimmy is correct: You will notice (at least as of today, Dec 1st 2016) when you go to submit your app for review and reach the Export Compliance walkthrough, you'll notice the menu now states that HTTPS is an exempt version of encryption (if you use it for every call):
I found this FAQ from the US Bureau of Industry and Security very helpful.
encryption
Question 15 (What is Note 4?) is the important point:
...
Examples of items that are excluded from Category 5, Part 2 by Note 4 include, but are not limited to, the following:
Consumer applications. Some examples:
piracy and theft prevention for software or music;
music, movies, tunes/music, digital photos – players, recorders and organizers
games/gaming – devices, runtime software, HDMI and other component interfaces, development tools
LCD TV, Blu-ray / DVD, video on demand (VoD), cinema, digital video recorders (DVRs) / personal video recorders (PVRs) – devices, on-line media guides, commercial content integrity and protection, HDMI and other component interfaces (not videoconferencing);
printers, copiers, scanners, digital cameras, Internet cameras – including parts and sub-assemblies
household utilities and appliances
Simple answers are Yes(App has encryption) and Yes(App uses Exempt encryption).
In my application, I am just opening my company's website in WKWebView but as it uses "https", it will be considered as exempt encryption.
Apple document for more info: https://developer.apple.com/documentation/security/complying_with_encryption_export_regulations?language=objc
Alternatively, you can just add key "ITSAppUsesNonExemptEncryption" and value "NO" in your app's info.plist file. and this way iTunes connect won't ask you that questions anymore.
More info: https://developer.apple.com/documentation/bundleresources/information_property_list/itsappusesnonexemptencryption?language=objc
You can follow these 3 simple steps to verify if your application is exempt or not: https://help.apple.com/app-store-connect/#/dev63c95e436
You may need to submit this annual-self-classification to US gov. For more info: https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
LOOKS LIKE HTTPS COUNTS
link to "Learn more":
https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
Just adding my personal interpretation of a very special case:
In my app the user has the option to go to a website themselves or let my app open Safari and Safari will call an HTTPS website. Could be any - own website, article etc etc. I interpret Safari making the actual HTTPS call, not my app and therefore answer the first question with No (or set the flag in the info.plist) and have no requirement to annually report.
If you're not explicitly using an encryption library, or rolling your own encryption code, then I think the answer is "no"