IRC Log Viewer » #firebreath » 2015-04-17

IRC Nick Time (GMT-7) Message
kylehuff 13:04 taxilian: that commit fixes the ID generation script, as the original method does not generate the same ID that chrome would, causing the loaded extension to not be able to talk to the native message host
taxilian 13:04 really? that's weird; it worked fine for me
kylehuff: in fact we originally had what you just commited, but we found it was the same as the other so we kept the shorter version
kylehuff 13:04 hmm, I don't know how that is possible. I tested it with a key that produces a known key in chrome, when signed in the old format, the id was very different
*known ID in chrome
*known ID in chrome
taxilian 13:04 huh
kylehuff 13:04 ah, I think I know whats going on
the python crypto library in some older versions does not export the SubjectPublicKeyInfo structure when calling publicKey()
or so it seems
taxilian 13:04 ahh
so it depends on the version you have installed
kylehuff 13:04 it appears so, on this machine, the old version works fine. on another, no dice.
I'm trying to verify which version range, so we can weight if supporting those older versions is worth it
taxilian 13:04 very interesting. the main disadvantage to the longer version is it has an additional dependency
kylehuff 13:04 okay, it isn't on the export, it is on the import... so, it won't matter when creating new ID's, it would only matter if you are using an existing key. if we don't foresee allowing them to use a predefined key, I can revert the changes.
taxilian 13:04 ahh
ahh
yeah, currently I think that's fine
kylehuff 13:04 okay, I'll revert the changes and if we want to later add the ability to use a predefined key, we could catch the specific versions and only add the extra dependency for those cases
taxilian 13:04 cool
so did you already move?
so did you already move?
kylehuff 13:04 yep. moved over the last few days. now, unpacked? pffft...
taxilian 14:04 hehe
I understand that =]
scjohn 14:04 raxilian: sorry I missed you yesterday, I have a 1.7 plugin that interfaces with a couple of hardware devices.
one of the devices uses a DLL for communication, the other provides a local TCPIP service that the c++ communicates with.
taxilian 14:04 okay; first thing to understand about firebreath 2.0 is that it is 100% async
scjohn the second thing to know is that it doesn't support activex yet =]
but that could be finished up if someone were motivated to do so
it's in the refactor branch; requires vs2013 on windows currently
mac xcode should work fine
scjohn 14:04 does 2.0 provide the same cross browser support as 1.7?
does 2.0 provide the same cross browser support as 1.7?
taxilian 14:04 yes/no/kinda more =]
yes/no/kinda more =]
once activex is finished it will be better than 1.7
scjohn 14:04 do you start with the prep scripts?
taxilian 14:04 it should be possible to make a plugin that will work with npapi, activex, and firewyrm
you'll want to start by using fbgen to make a new project
you'll want to start by using fbgen to make a new project
then yes, the prep scripts but you only do one project at a time now so you'll need to specify the path to the script and the build dir
e.g. prep2013.cmd projects\mynewplugin build
scjohn 14:04 do the plugins still install the same (ie I have an Windows installer)?
taxilian 14:04 kinda =]
the plugin installs the same
but to use it in chrome w/ native messaging you need to also install the native message host and extension
scjohn 14:04 nice
taxilian 14:04 I have the windows installer locally updated to do all of that
not sure if I've updated fbgen already or not
I'm still tweaking
not sure if I've updated fbgen already or not
scjohn 14:04 do you have a timeline? ie when will it be possible to build a production project on 2.0?
taxilian 14:04 I'd call it beta quality right now; if you're willing to test and work on it I'd say you can do it now
I'd call it beta quality right now; if you're willing to test and work on it I'd say you can do it now
but you'll need to be willing to fix things
it would actually be a huge help; so far kylehuff is the only one who has actually helped with this, which frankly doesn't leave me really motivated to finish beyond what I need myself
scjohn 14:04 What is FireWyrm ?
taxilian 14:04 do some reading here: http://www.firebreath.org/display/documentation/FireBreath+2.0%3A+Browser+Plugins+in+a+post-NPAPI+world
that's got the general details of the plan
firewyrm is a json-based protocol that we use to communicate with chrome, but could theoretically be used across any medium able to pass json
scjohn 14:04 ah, i see that in the document today, I missed it yesterday
taxilian 14:04 I just updated it in the last week sometime
scjohn 14:04 Do you know if Firefox is planning on removing NPAPI support?
taxilian 14:04 not that I know of
I'm sure they'd like to, but haven't announced any plans thus far
I'm sure they'd like to, but haven't announced any plans thus far
if they do we can almost certainly retain support using FireWyrm and js-ctypes
scjohn 14:04 My plugin is a thin layer that lets me communicate with a couple of hardware devices.
Would I still define the basic plugin the same way, per the Interacting with Javascript from the wiki?
taxilian 14:04 pretty close, yes
the main difference is that it would return a Promise instead of just a result
and if you want you can return a Promise<T> instead of just T
and if you want you can return a Promise<T> instead of just T
it's still the same framework, just async
scjohn 14:04 ok, thanks for your help.. I will need to get a development environment setup (I am at vs 2010 now), hopefully I will give this a try next week
one more thing, by "it doesn't support active x yet" It would not work on IE