Careful about installing Influxdb and Telegraf on the same system via RPM (maybe DEB too), they both share common paths and filenames, and cause one (or the other) not to start.
I am really excited about telegraf, but am worried about long term maintenance of yet another stats collector. It is very easy to setup, and seems like it will be quiet easy to extend.
We'll have to fix the issues of installing on two systems. For the issue linked to InfluxDB I assume it was for the client tags. The tagging issue in Telegraf was actually a problem with the InfluxDB client.
Anyway, we're committed to maintaining this and pushing it forward
The dual-installation issue the grandparent mentioned also exists for DEB, which is what prompted my PR. Any way you can help with https://github.com/influxdb/telegraf/pull/23? I really want to install InfluxDB and Telegraf on the same system, but I don't want to maintain a fork.
I've considered it but haven't made the jump yet. Pyr gave a presentation a few weeks ago that suggested his company is already using it and further development is coming.
Would it be possible to use this method against something like a Java app loaded in tomcat where as to test for bugs within a certain library? Say, for instance that I wanted to see if certain malformed xml posts were able to cause unexpected behaviors in a passing endpoint? As I write this I think that in some cases some kind of httppenetration tool might be more suited but I think im wondering what would happen with a tool that isn't necessarily confined to a ruleset and pattern matching.
The afl fuzzer relies on compiling C code with its own compiler, so I think it's limited to only C based programs.
What you may want is to use something like `quickcheck` (scalacheck or clojure's test.check I guess?) to send lots of "arbitrary" xml at your code and see what breaks. With sufficiently interesting definitions of "arbitrary" you can probably find bugs.
That approach would be testing inside the process, as opposed to passing in whole http requests. But if you know a section of code is more vulnerable than others, focus on it. No need to test all of tomcat's http parsing when you really care about your specific library.
Curious how/if Redhat would deal with date-based versioning. 2.6.32 was originally released ~6 years ago and for-better-for-worse their frequent security patching would make the original release date fairly irrelevant.
Agreed, even more so because RedHat doesn't just backport security fixes, but also features (one example is the btrfs stuff in RHEL6, which, according to a developer, is from Linux ~3.8 IIRC).
I think the more interesting part is the comments that crept out of the wood work days after the article was posted to HN.
hautit 5 days ago (1 comment - account created 324 days ago)
Get over it, CBInsights, your UX sucks.
theUXclub 4 days ago (brand new account)
CB Insights, cheap and creepy as always. A 'low-drama' group of people that decided to tweet and share the story all over the place claiming something like 'Look! They copied us!'- Your UX is bad as hell, I wouldn't be very proud. Plus, your site is Bootstrap (a framework created for people who have no skills or time to invest on CSS or design), did you also invent it and they copied you as well?
frumpywooly 4 days ago (brand new account)
"...12 folks from their team have signed up for our free trial since September including the CEO, head of product, designer, product manager and a senior ruby developer." CBInsights, creepiest company in America
CB Insights actions, arguably, constitute a large scale smear campaign that is not adequate to the original transgression of the startup.
Your comment, arguably, constitutes a low scale smear campaign as you have no proof that startup founders have posted those comments. Any other CB Insights competitor/enemy could use that opportunity.
>CB Insights actions, arguably, constitute a large scale smear campaign that is not adequate to the original transgression of the startup.
"Blame the victim" much?
They just reported it on the web AFAIK. What else would be "adequate to the original transgression of the startup"?
>Your comment, arguably, constitutes a low scale smear campaign as you have no proof that startup founders have posted those comments.
Sure, no hard proof. I only have a guess, based on decades of living in a human society, that accounts that were created days before, and that say the same things, and in favor of the transgressor, are somehow related to them...
Is there any competing theory? Random internet people that decided to sign up to HN just to vent against a company?
Yeah, a competing theory that I've included in my original comment. Anyone with a grudge against CB Insights could have registered those accounts.
>Random internet people that decided to sign up to HN just to vent against a company?
Obviously, trolls exist. Copyright/plagiarism/"inspiration" discussions are a feeding grounds for those kind of people.
That's two competing theories. And yeah, it's ironic to state with confidence that someone is "actively running a smear campaign" with no plausible data confirming the statement.
Re #2: Unless you are a contractor. I was shocked to learn how much the about-to-retire ~20-30 year guys were making compared to my mid/senior level long-term contractor position was paying.
I am not sure about medium-risk public trust positions, but for high-risk public trust positions (think access to PII, social security # type stuff) they require an in depth personal history, including a meet and greet with an investigator (usually ex-law enforcement, so I was told).
Protip: Contractor or FTE, make sure you specifically ask HR whether or not there will be an additional screening, and whether or not it is a 'public-trust' position and what level that would be following your hiring.
I was pretty miffed when 'they' told me after the fact that my position required an additional background check and that my continued employment would be predicated on the outcome.
There was also this one[1] from a couple of years ago (that you may be referring to?) where with a inexpensive kit, a thief could intercept the drivers key fob transmissions to open the car, and then a ODB programmer to pair the car with a key blank.
I heard of another variant where a jammer was used to stop the car from locking in the first place, whereby goods could be stolen. With the ODB programmer and the key blank the car could then also be stolen.
I have heard that the cars without real ignition keys (in other words, those rfid fobs without a mechanical ignition lock) that it could be possible to authorize a new key by communicating on the OBD2 connector. You do not need access to a working key if this is true, but it is my impression based on some things that I have heard that the private part of some asymmetrical cryptographic material must be known. Whether it varies from car to car, I'm not sure. (This system is called CAS by BMW)
However, in the cars with real ignition locks, the immobilizer is not as easy to defeat as the "nakedsecurity" piece implies.
Since 1994 or so (with the introduction of the EWS2 system) the ignition key contains an RFID tag with a permanent shared secret and a password which is updated every time the key is used. It has always been possible to get close to such a key and read it, then write the information into a new key. Since the password is updated when the key is turned to the 'run' position, as soon as either of the "identical" keys are used, the other will stop working.
To authorize a new key on the EWS2 or EWS3 systems using the diagnosis connector, the new key must contain a shared secret already known by the EWS brain. The factory programmed ten such secrets into each EWS brain during manufacture, and four keys were delivered with the new car when it was sold. When a new key is requested through the parts department, that key is delivered with one of the known shared secrets. Then it can be authorized with a diagnosis request.
To change the shared secret information in the EWS brain to arbitrary information, or to discover the shared secrets known by the EWS brain, it must be removed from the car, physically opened and bootloaded. (It's one of the 68hc11 processors, and there are test points on the board for the mode select pins, manipulating these can place the hc11 in a mode to run a bootloader delivered over the serial line.)
(One difference between the EWS2 and EWS3 systems is that the EWS2 brain sent another, static shared secret to the engine control to signal permission to start - a simple 32 bit word. In EWS3, this communication involves some cryptography.)
It is possible that the database of shared secrets became available when the "Heartbleed" flaw became known. I have heard that their VPN was attacked. If this material were stolen, probably the bitting information required to cut a mechanical key were stolen along with it.
The keyless entry remote of these BMWs is more like the ones used in every car, even though it is part of the same ignition key with RFID tag for immobilizer: the key has a seed and does some transformation every time a remote button is pressed.
Indeed. You can do this using the BMW manufacturer software (which is comically not hard to find), at least for the E9* series of BMW's. Not sure about the newer F3* series, but I wouldn't be surprised.
I think they really did not count on tools like NFS to find their way into the de facto 'public domain.' However when CAS was designed, they knew (or should have known) that somehow all the manufacturing-side tools were getting out. Also some of the regional technical people who support the dealers carry them around on their laptops. A couple of beers can earn you a lot of secrets sometimes.
