IRC Log Viewer » #firebreath » 2013-02-22

IRC Nick Time (GMT-7) Message
DooZer_ 10:02 Hello~~~~~~~~~~~~~
taxilian 10:02 good morning~~~~~~~~~~~~~~
DooZer_ 10:02 here night :)
taxilian 10:02 morning somewhere
DooZer_ 10:02 i have one question
can i ask?
taxilian 10:02 I believe that is the point of an irc chat room, yes
DooZer_ 10:02 how to find FB Version??
on MacOSX
taxilian 10:02 how did you get it?
from git or downloading the archive?
DooZer_ 10:02 maybe downloading
taxilian 10:02 look at the "version" file
it has a git commit hash
DooZer_ 10:02 commit date?
taxilian 10:02 commit hash. with that you can look on github and find the date
DooZer_ 10:02 i can't find version in git hub project
commit date 14 March 2012
taxilian 10:02 then you're on 1.6
I recommend updating to 1.7
DooZer_ 10:02 oh~
so am i build trouble ?
taxilian 10:02 I do not understand the question
DooZer_ 10:02 i used to FB one years ago
but now i can't build FB
taxilian 10:02 that's a little unspecific
though thinking of some common issues on mac os, I'd update cmake. you'll have to delete the /usr/bin/cmake, ccmake, cpack, cmake-gui, cmakexbuild, and ctest symlinks first
and updating to 1.7 is still a good idea
DooZer_ 10:02 already update cmake but not delete old version
is that problem?
taxilian 10:02 there are no breaking changes, so you shouldn't have to change your code
type cmake --version
see if it's the new one
probably isn't
DooZer_ 10:02 Ignoring CMAKE_OSX_SYSROOT value: /Developer/SDKs/MacOSX10.6.sdk because the directory does not exist. Call Stack (most recent call first): /Applications/CMake 2.8-10.app/Contents/share/cmake-2.8/Modules/CMakeSystemSpecificInformation.cmake:36 (include) CMakeLists.txt:19 (Project)
you know this error?
a part of error log
taxilian 10:02 did you delete your build/ directory and rerun the prep script?
DooZer_ 10:02 not delete
taxilian 10:02 do so
DooZer_ 10:02 i'll try
wow! it works!!!
taxilian 10:02 congrats
but I still recommend updating to firebreath 1.7 =]
kylehuff 10:02 in the build/projectName/CMakeFiles/projectName.dir there is a file "link.txt", in which one of my included libraries is linked. My question is, where/how does it decide what linker flags get passed? I am trying to influence the usage of "-ldl". Is this something that comes from library being linked or something in cmake?
taxilian 10:02 kylehuff: the linker flags are partly generated, partly configured
I don't know exactly on that flag
but you can configure link flags for a given target
kylehuff 10:02 yeah, I'm trying to omit the "-ldl" flag when compiling on BSD
but I didn't find any reference to that linking when using grep
taxilian 11:02 I really don't know :-/
kylehuff 11:02 thats okay. thanks anyway. thought I would ask before crashing deeper, or god forbid, recompiling my library if need be.
masu 11:02 do anybody know where does the "cout" output from browser-firebreath-plugin proces writes to?
taxilian 11:02 well, if he'd stick around long enough for me to get back to my computer, I could have answered his question
oliver__ 13:02 Hey there! Is there any simple way to securely request input from the user in firebreath? Currently, I'm encrypting files within the plugin using gnupg, which has its own password entry wrapper. I'd like to remove that dependency using my own password entry. Is there a lightweight UI library that allows me to capture input while not bloating the binary?
taxilian 14:02 oliver__: you could use a system dialog of some sort, most likely
oliver__ 14:02 taxilian: I'll look into this. The information on this topic is sparse, and i'm no expert. I was looking into simple cross-platform UI libraries for dialogs, but it's either full-blown or opengl with rather awkard text input
taxilian 14:02 I don't know of any good options for that
kylehuff 15:02 I wouldn't put my private-key passphrase into anything other than the configured gpg-agent
nor would about 90% of the hundreds of gnupg users I associate with
oliver__ 15:02 kylehuff: Using gnupg is still the best option, but a large number of potential users are scared off when requiring gnupg.
Thus i'm trying to make the dependency opt-in, and use some other pinentry scheme for file encryption.
As I'm deploying pairing-based cryptography alongside AES-GCM within firebreath, having some reliable [apart from gnupg] input method aside the DOM would be highly desirable
kylehuff 15:02 that is all well and good, I'm just saying -- almost nobody I know would input their passphrase into a dialog other than pinentry. this is due to the kludge of pipes or gpg invocation parameters (i.e. --passphrase "xxx") required to be passed around, even when using libgpgme.
oliver__ 15:02 The key here is to find some method of choosing/confirming a password from the user would be nice _iff_ gnupg is not available, thus not using gpg at all.
kylehuff 15:02 also, IMO, it sets a dangerous precedence, given that it conditions the user to input their passphrase into random dialog boxes, which is compounded by the exposure of a private-key methods available to the browser. The latter I think is less of an issue with a unified source for passphrase retrieval.
ah, okay. I misunderstood your process. carry on mate.
oliver__ 16:02 But your argument also holds for gnupg-pinentry if carried out through the browser. It also introduces the risk of attacks through caching of the private key and circumventing [repeated] calls to pinentry
kylehuff 16:02 yes, as I stated, exposing private key operations to the browser is an issue -- but I think less of "best practice" influencer to the average user.
making gnupg private-key operations available to the browser is exactly why my own FB plugin only accepts requests within the scope of the parent browser extension.
oliver__ 16:02 How did you implement that? My Browser extension (which employs the firebreath plugin) does that for chrome - as you can restrict actions from that extension only
but in Firefox, I have to rely on the requested URL to detect the extension, and that is rather hacky
kylehuff 16:02 the plugin is private within chrome, and in firefox, if the hosting DOM is not "chrome-extension://{extensionid}", it refuses to register any methods and exits.
oliver__ 16:02 can you elaborate on the firefox part? I'm using MPI to bundle the plugin and extension into one XPI, but the plugin is still publicly available
kylehuff 16:02 oliver__: https://github.com/kylehuff/webpg-npapi/blob/master/webpgPlugin/webpgPluginAPI.cpp#L90
oliver___ 16:02 meh.. disconnected - sorry
kylehuff 16:02 did you get the link though?
oliver___ 16:02 Nope, must've been lost in the timeout
kylehuff 16:02 https://github.com/kylehuff/webpg-npapi/blob/master/webpgPlugin/webpgPluginAPI.cpp#L90
it isn't very elegant, but if the plugin is not hosted via an extension, it only registers a few properties (version and status properties)
I think in that version, it is only checking protocol://, nothing more, as that is a generic library
oliver___ 16:02 okay, that would be my next question. Currently, some other (possibly malicious) extension could call methods on the plugin.
kylehuff 16:02 it also is outdated, I see I need to merge my latest branch into trunk
oliver___ 16:02 but it shouldn't be too hard to hardcode the extension's id, given its private key uniquely decides that
kylehuff 16:02 yes, but then again, given what an extension can do (think nsiFileManager), if you don't trust the other extension installed, you are kind of an idiot. =c )
oliver___ 16:02 yeah, that'd be foolish ;)
kylehuff 16:02 thats not to say it shouldn't be more concise though. I'm just speaking as a general notion.
oliver___ 16:02 Alright, thanks for your valuable input! I'll first implement that check and test my options.
Yes. I prefer to specialize that constraint as much as possible, even if it might not be necessary based on the user's trust.
kylehuff 16:02 also, I'd recommend doing a more concise check than just location.find - something that implicitly checks the protocol. I worked something out, but it is in a local repo on another machine, otherwise I'd give you a reference.
oliver___ 16:02 I'm following your updates on github, should you incorporate it into any of your projects, i'll see it :)
kylehuff 16:02 yeah, I'll probably push those changes this weekend. currently working on building under *BSD
oliver___ 16:02 okay, I'll have a look at it. Gotta run - Thanks again for the input!
kylehuff 16:02 also, if you come up with something better, I'd be interested in seeing it. (I am most definitely not a C programmer)
np; good luck mate.
oliver___ 16:02 Me neither - but I'll be back to report my solution should i find it ;)
kylehuff 16:02 woot! just successfully built under FreeBSD.
taxilian 16:02 nice =]
johannes 16:02 ah, i should cleaup my solaris patches ... oh i should do sooo many things ...
taxilian 17:02 lol
hxmeadroom 19:02 Anyone mess with add_firebreath_library(openssl) ? It doesn't seem to work as I expected.
haxmeadroom 19:02 I add the line, but It doesn't seem to link with the lib file or setup the include directories.
haxmeadroom 19:02 and when I manually reference the openssl .h files, I get this- error LNK2026: module unsafe for SAFESEH image.
haxmeadroom 19:02 Disabling SAFESEH in the linker options seemed to work, just don't know how kosher that is.
taxilian 19:02 I haven't the slightest idea what SAFESEH is
so I can't help you there
I have used openssl that way (I'm the one who originally set it up) but no idea what SAFESEH is
haxmeadroom 19:02 It's for the structured exception handler
taxilian 19:02 what platform is this?
haxmeadroom 19:02 How did you use openssl exactly? What line did you put in what file? Did you have to manually add the openssl/include directory to the project includes?
I'm compiling vs2012
Win8
taxilian 19:02 I haven't used it on vs2012
I used it with HTTPService
and libcurl
it might not work with vs2012
might be that you need a newer version of openssl
actually it probably won't work with vs2012; it was built with vs2010
haxmeadroom 20:02 Ah..
Yeah, I'm getting an exception, not sure if it's my code or the linker SAFESEH issues yet
Wish we hadn't switched to vs2012.. It crashes all the time
taxilian 20:02 you could probably build it yourself
haxmeadroom 20:02 Yeah, I may have to.
taxilian 20:02 here are the instructions I created back in the day: https://gist.github.com/taxilian/1095427
might still even be somewhat accurate, who knows? =]
gotta run now
good luck
haxmeadroom 20:02 Sweet, thanks!
kylehuff 21:02 just FYI, firebreath plugins appear to work flawlessly in FreeBSD. The only trouble I had was with the 3rd party libraries used by my project. (granted, my plugin doesn't draw anything)
taxilian 21:02 huh. good to know =]
kylehuff 21:02 not sure if anyone ever tried in bsd before, but it works.
taxilian 21:02 so the "X11" tag instead of calling it "linux" was actually accurate!
kylehuff 21:02 yes, at least it appears so. I'll eventually get around to testing netBSD and openBSD, as well as openSolaris. relevant patches will ensue if they are needed.
I still don't know where that linker flag was coming from though. I had to remove it from the link.txt file after prep, before build. still looking into that one.
taxilian 22:02 hmm
that's weird
kylehuff 22:02 I found it. don't know how I missed it. I'll submit fix as soon as I'm sure nothing else is broken