|
ripgrep is fast 💨
|
# ? Dec 8, 2017 10:15 |
|
|
# ? Jun 5, 2024 03:45 |
|
man i just got my muscle memory to remember ack, tell me why i should try out something else
|
# ? Dec 8, 2017 11:01 |
|
the silver searcher (ag) and ripgrep are both insanely fast compared to grep. not sure how any of them compare to ack, never used it.
|
# ? Dec 8, 2017 11:20 |
necrotic posted:the silver searcher (ag) and ripgrep are both insanely fast compared to grep. not sure how any of them compare to ack, never used it. the platinum searcher (pt) is nice on windows spacemacs
|
|
# ? Dec 8, 2017 11:29 |
|
necrotic posted:the silver searcher (ag) and ripgrep are both insanely fast compared to grep. not sure how any of them compare to ack, never used it. use ripgrep (edit: or platinum searcher as suggested above), nice re2-style non-backtracking implementation (in the form of rust regex) backing it, consistenly fast and good ack is perl regexes (silver searcher a mix of raw boyer-moore and the rest backed by pcre), so as usual it is fast except when it isn't (and, no, this is not likely to matter hugely for your own personal searching needs, but if you get to choose freely anyway~) Cybernetic Vermin fucked around with this message at 11:59 on Dec 8, 2017 |
# ? Dec 8, 2017 11:35 |
|
ah well pcre4lyf so suck it, vermin
|
# ? Dec 8, 2017 13:16 |
|
eh, in *this* context liking pcre is fine, but you know my opinion in general :p
Cybernetic Vermin fucked around with this message at 14:05 on Dec 8, 2017 |
# ? Dec 8, 2017 13:23 |
|
just finishing up an endless slog of a paper ok backreference semantics and feeling a bit worn out on the subject. getting drunk tonight.
|
# ? Dec 8, 2017 14:06 |
|
no lets go into a several page debate over the best regex library
|
# ? Dec 8, 2017 15:03 |
|
Meat Beat Agent posted:ag | peanuts
|
# ? Dec 8, 2017 15:50 |
|
egrep in the streets, fgrep in the sheets
|
# ? Dec 8, 2017 17:52 |
|
Meat Beat Agent posted:ag | peanuts paging graph, graph please report to the Security Fuckup Megathread. thank you
|
# ? Dec 8, 2017 17:52 |
|
Cybernetic Vermin posted:just finishing up an endless slog of a paper ok backreference semantics and feeling a bit worn out on the subject. getting drunk tonight. its cool no worries
|
# ? Dec 8, 2017 20:45 |
|
Cybernetic Vermin posted:use ripgrep (edit: or platinum searcher as suggested above), nice re2-style non-backtracking implementation (in the form of rust regex) backing it, consistenly fast and good I remember RE2 having a fair bit of backtracking. Especially in Claire's version. Cybernetic Vermin posted:eh, in *this* context liking pcre is fine, but you know my opinion in general :p PCRE is terrible, it should be on consoles only.
|
# ? Dec 8, 2017 21:08 |
|
The Secfuck hit my email today:quote:Hi Harik, It starts out bad and it keeps getting worse. I have so many comments I want to give them. Starting with , moving through various stages of maniacal laughter, and ending with A year ago I offered to help and vet their security a year ago but they "knew what they were doing." I had no idea what they'd actually chosen to do until today and holy gently caress it's a tire fire.
|
# ? Dec 8, 2017 21:08 |
|
it's fine you just disable bluetooth and use a key instead, no one's managed to beat that yet
|
# ? Dec 8, 2017 21:20 |
|
What's your favorite part? Mine is probably JavaScript code:
|
# ? Dec 8, 2017 21:24 |
|
no one is immune to iot shenanigans
|
# ? Dec 8, 2017 21:30 |
|
the part where the researchers waste time explaining that the pincode isn't used at all in the getAuthor part of the protocol just reflected back to the client then call it a vulnerability. after showing that the pincode is really just the pairing code
|
# ? Dec 8, 2017 21:33 |
|
Wiggly Wayne DDS posted:the part where the researchers waste time explaining that the pincode isn't used at all in the getAuthor part of the protocol just reflected back to the client then call it a vulnerability. after showing that the pincode is really just the pairing code I'm going to be tearing this apart myself to figure it out - since it'd be completely obvious that any number you enter in the app works to unlock the safe, the check that they match must be done in the app itself against something it saved? I wonder if the bluetooth PIN and device PIN are getting conflated somewhere. Unfucking this mess is probably going to fall to me, which means yay chinese written app and firmware and hardware with chinese ICs that only have chinese datasheets and chinese support. I loving hate being right.
|
# ? Dec 8, 2017 21:57 |
|
Harik posted:The Secfuck hit my email today:
|
# ? Dec 8, 2017 22:01 |
|
Harik posted:I'm going to be tearing this apart myself to figure it out - since it'd be completely obvious that any number you enter in the app works to unlock the safe, the check that they match must be done in the app itself against something it saved? I wonder if the bluetooth PIN and device PIN are getting conflated somewhere. e: the "something that it saved" would be the bluetooth pairing code allowing it to talk to the machine at all surely
|
# ? Dec 8, 2017 22:28 |
|
anthonypants posted:give them the comments Wiggly Wayne DDS posted:i'd guess that they had it implemented properly at some point then someone went "why are we using the same code twice to authenticate the channel and the safe combo" and someone had the idea to solve that issue by ripping out parts of the safe combo validation but didn't feel comfortable altering the protocol itself
|
# ? Dec 8, 2017 23:19 |
|
Harik posted:The Secfuck hit my email today: quote:However the safe does not verify the pin code, so an attacker can obtain authorization and unlock the safe using any arbitrary value as the pin code. I mean of course, who needs a code for a safe?
|
# ? Dec 8, 2017 23:36 |
|
nsa needs to remove specific event log entries to hide their tracks and make sure they can never be recovered, just one catch: https://blog.fox-it.com/2017/12/08/detection-and-recovery-of-nsas-covered-up-tracks/ quote:Fox-IT discovered that when eventlogedit is used, the to-be-removed event record itself isn’t edited or removed at all: the record is only unreferenced.
|
# ? Dec 9, 2017 00:21 |
|
Wiggly Wayne DDS posted:nsa needs to remove specific event log entries to hide their tracks and make sure they can never be recovered, just one catch: apparently someone at the nsa never played uplink. gotta upgrade log deleter to v3
|
# ? Dec 9, 2017 00:25 |
|
Trabisnikof posted:apparently someone at the nsa never played uplink. gotta upgrade log deleter to v3
|
# ? Dec 9, 2017 00:42 |
|
Trabisnikof posted:apparently someone at the nsa never played uplink. gotta upgrade log deleter to v3 man now i want to play that through again
|
# ? Dec 9, 2017 01:45 |
|
Ciaphas posted:man now i want to play that through again
|
# ? Dec 9, 2017 01:49 |
|
if anyone's shepherded a CVE who would be willing to give me advice (here or in PM) it'd be appreciated. I've dealt with security breaches before but never had to run the reporting/responding part, and nobody else here has either. Trying to get mitigation information out to people now that I've convinced marketing that "head in the sand and pretend nothing happened" isn't a valid response.Trabisnikof posted:apparently someone at the nsa never played uplink. gotta upgrade log deleter to v3
|
# ? Dec 9, 2017 01:50 |
|
Harik posted:if anyone's shepherded a CVE who would be willing to give me advice (here or in PM) it'd be appreciated. I've dealt with security breaches before but never had to run the reporting/responding part, and nobody else here has either. Trying to get mitigation information out to people now that I've convinced marketing that "head in the sand and pretend nothing happened" isn't a valid response. https://cve.mitre.org/about/faqs.html https://cve.mitre.org/cve/request_id.html
|
# ? Dec 9, 2017 02:08 |
|
Meat Beat Agent posted:ag | peanuts idgi
|
# ? Dec 9, 2017 02:20 |
|
vOv posted:idgi
|
# ? Dec 9, 2017 02:23 |
|
anthonypants posted:here is a hint oh
|
# ? Dec 9, 2017 02:29 |
|
Meat Beat Agent posted:ag | peanuts
|
# ? Dec 9, 2017 02:38 |
|
Proteus Jones posted:https://cve.mitre.org/about/faqs.html the CVEs are already filed by a third party, I'd be the vendor of the vulnerable product. Lots of CVEs have links to mitigations and fixes, but I don't see how to get them added on. that's separate from the "vendor statement" which is just the PR bullshit used to downplay how bad they hosed up. it sounds like this needed to have been done before it went public but I'm just picking up the pieces of previous idiocy at this point. fortunately bluetooth unlock is a dumb fluff feature and it's trivial for the end user to turn off.
|
# ? Dec 9, 2017 02:44 |
|
necrotic posted:the silver searcher (ag) and ripgrep are both insanely fast compared to grep. not sure how any of them compare to ack, never used it. remember how in like 1989 a ton of Mac software was named like this? Like "The [software noun]" would have to dig up my Macintosh Bible to come up with actual examples
|
# ? Dec 9, 2017 03:08 |
|
Harik posted:the CVEs are already filed by a third party, I'd be the vendor of the vulnerable product. Lots of CVEs have links to mitigations and fixes, but I don't see how to get them added on. that's separate from the "vendor statement" which is just the PR bullshit used to downplay how bad they hosed up. I don't think you can get that stuff added. After it's submitted, it's a done deal as far as I know. I'd simply release your company's announcement through your regular channels and reference the CVE like: quote:SAFE MAKING Co.: This Thing We Did What hosed Up (CVE-2017-XXXXX)
|
# ? Dec 9, 2017 04:15 |
|
atomicthumbs posted:remember how in like 1989 a ton of Mac software was named like this? Like "The [software noun]" The Good Finder The Utility That's $40 Registration On The Mac But It's Free On Windows Or Maybe Like $5
|
# ? Dec 9, 2017 05:05 |
|
|
# ? Jun 5, 2024 03:45 |
anthonypants posted:here is a hint idgi
|
|
# ? Dec 9, 2017 09:29 |