FAQ for API Keys and App Signing

[neveroffline]

@viljoviitanen - I agree, What automating method you prefer:

1) A web service (authenticated)

OR

2) A keytool (+ a personalized key you download)

All app developers are encouraged to answer this and I'll try to add it to the long list of to-do(s) I've got going regarding app signing

Some sort of key we can use to trigger on your end the new updated app without having to go through A-C repeatedly.

We have:
A. Upload app.
B. Download sig.
C. Upload Sig.

Can we have D, authenticate update, no need for A-C (on 3rd party repos) if you already have the xml sig for a prev version?

IE: newverison=1.03&repo=url&auth=token - token can be based on our pwds already or something else other than our key.

EDIT: This way you would know it's us, can authenticate, grab the new zip, gen a new sig if you have to, and keep it internally on record.

[viljoviitanen]

@viljoviitanen - I agree, What automating method you prefer:

1) A web service (authenticated)

OR

2) A keytool (+ a personalized key you download)

All app developers are encouraged to answer this and I'll try to add it to the long list of to-do(s) I've got going regarding app signing

I prefer whichever is the easiest to automate in a shell script So maybe #2, depending on what kind of a tool you have in mind. I'd be comfortable with just a private key and instructions on how to make a signature with openssl but I'm sure not many developers would like that. But there's always the current manual method. I suppose this would be easier for you to implement as well. Just give me the key you already created for me and describe the process you make the sigs with...

Btw if you mean by web service a "real" web service with a soap interface, wsdl etc, then no thanks. I get to deal with that crap with my day job more than I'd like to.

[Lilo]

@neveroffline - application signatures are a result of a signed zip file, we can't skip the upload process - I'll think about the implications of providing a url for the source but this will not solve the fact that you'll need to get a new signature and upload it to you app location.

Btw if you mean by web service a "real" web service with a soap interface, wsdl etc, then no thanks. I get to deal with that crap with my day job more than I'd like to.

rofl.

I thought more about a URL which you can post you zip file to and the response will be the signature (assuming it passed validation). Something that can be done with one line of curl.

[viljoviitanen]

I thought more about a URL which you can post you zip file to and the response will be the signature (assuming it passed validation). Something that can be done with one line of curl.

Super! I'll change my pick to this one.

[neveroffline]

@neveroffline - application signatures are a result of a signed zip file, we can't skip the upload process - I'll think about the implications of providing a url for the source but this will not solve the fact that you'll need to get a new signature and upload it to you app location.



rofl.

I thought more about a URL which you can post you zip file to and the response will be the signature (assuming it passed validation). Something that can be done with one line of curl.

I agree, that's kind of what I was expecting. I know you have to go through A-C first. Not sure you read my post edit. My option, D, is to hit your end with the URL of our Application with our credentials, w/e those are, and you curl out on your end, grab the app, sign it, and reply with that sig file. Uploading the app via POST to a URL (with some sort of credentials) and then you signing it works in the exact same way, only you aren't grabbing the file (which I think you should).

Either way, I think this is the kind of automation we need if we just want to hit a button/run a script to upload app, sign it, download sig, upload sig to repo internally.

[dotsa]

Yesterday we opened up signups for API keys at http://boxee.tv/developer and invited all Boxee developers to hop on the train. The introduction of API keys has raised a lot of questions - I thought it would be prudent to kick up a forum thread to answer the most common ones and keep it updated over time.

How close are we to ability to send the zip and get sig or error back through some sort of automate-able API? Curl-based upload or a webservice or something like that...

Did this ever happen?

Build automation / deployment for Boxee development is a no go without this. This guy (https://github.com/tommysqueak/GreatBoxee) is stuck with his Ant build script. I am stuck with WAF automation script.

[Lilo]

How close are we to ability to send the zip and get sig or error back through some sort of automate-able API? Curl-based upload or a webservice or something like that...

Did this ever happen?.

This is currently planned as part of the server api, it will be done in the near future (sorry, but I can't give you an exact date).

There is a thread for community feedback and request for the new server api here:

http://forums.boxee.tv/showthread.php?t=32102

This point is already listed but you might want to take a look anyway.

[dotsa]

This is currently planned as part of the server api, it will be done in the near future (sorry, but I can't give you an exact date).

There is a thread for community feedback and request for the new server api here:

http://forums.boxee.tv/showthread.php?t=32102

This point is already listed but you might want to take a look anyway.

Just a thought on that... If the sig is derived by hashing the zip in some way that can be duplicated by dev, just sending a hash as text + contents of descriptor.xml by dev to you over plain form-encoded HTTP Post and having a sig sent back might be easier to implement as simple API.

I can sort of understand the difficulty of wrapping an ability to "send a potentially-large file" into a manageable API. You have to unzip the package, look at contents...
Sending a hash + meta to you for signing, and Boxee app, later, deriving the same hash from the zip might be a more manageable approach for your server API implementation. I, as a dev, certainly don't mind doing more work on my side, as long as I can automate the steps.

Daniel.

[viljoviitanen]

Just a thought on that... If the sig is derived by hashing the zip in some way that can be duplicated by dev, just sending a hash as text + contents of descriptor.xml by dev to you over plain form-encoded HTTP Post and having a sig sent back might be easier to implement as simple API.

I can sort of understand the difficulty of wrapping an ability to "send a potentially-large file" into a manageable API. You have to unzip the package, look at contents...
Sending a hash + meta to you for signing, and Boxee app, later, deriving the same hash from the zip might be a more manageable approach for your server API implementation. I, as a dev, certainly don't mind doing more work on my side, as long as I can automate the steps.

Daniel.

But then boxee would not know what was signed. I would guess boxee wants a copy of the code being signed, even though they do not check the code "online", they can investigate later and if needs be, invalidate the signature.