@thesecretmaster I'd prefer not to get multiple emails for the same failure. Are the tests actually doing different things? So far, the CircleCI UI appears significantly better to me. However, that's largely based on the only failures I've seen from GH actions saying "We are currently unable to download the log. Please try again later." (even hours after the test), which is completely useless.
Ah yeah I understand that. I think that for the most part they should both stay passing from here on out. I'd like to give it a week to make sure my fixes actually worked, but after than we can disable one or the other. I just like GH actions because they're built in and I like the YAML format better, but it's not a strong preference.
@thesecretmaster I'd feel a lot better about it, if it actually showed me the logs and not "We are currently unable to download the log. Please try again later." That, quite literally, makes it near-useless for figuring out what the problem is. None of the failures I've looked at show any information beyond that.
Looks like my issue is PEBKAC. However, it requires me to trust JavaScript. content from actions.githubusercontent.com, which I have blocked because githubusercontent.com is something I consider insecure.
Why did they use a subdomain off of githubusercontent.com? It's not user content.
actions. may be different, though - sounds like a CDN for Actions stuff only, which can be user-contributed for custom actions, but isn't browser-executable if that's the case
i'm not really sure this is a bug in SD because if a DNS record changes that's beyond SD's scope
we don't control DNS really, we'd need a separate watch on any suspicious IP (except if it's shared hosting like GoDaddy or such we can't just flag all of hosting necessarily, that's a ton of Falses)
also geolocated IP results are equally unpredictable
@ThomasWard What you said there made sense. It sounds like SD just sees different IP addresses. I was assuming tripleee would take a look at it and make an evaluation, given that they opened the issue. There's still work that could be done with respect to the overall issue (e.g. some more IP addresses could be watched, or some removed), but the problem doesn't appear to be that SD has a bug that doesn't see the IP address.
However, it sounds like a real solution is more than we want to get into. It just may not be possible to accurately detect some, or even a large number of, spam sites using an IP address. OTOH, it has appeared helpful in other instances.
@Makyen true. Caching DNS results requires a lot more logistics to it, and to be fair could be very tircky, we may as well just watch on those domains as they come across it. My two cents
but i'll let tripleee take a look
it helps that I have passive dns database accesses
Basically, it looks like detecting on the site's resolved IP address is useful in some instances, but not in others. For some, it's probably going to have FP, as they get switched to other domains. So, it looks like a detection which will have its uses, but not be perfect, and have cases where it's really counter-indicated to use it.
@thesecretmaster I re-ran the workflow. The results on CircleCI and on GH Actions are substantially different. I wanted to try running the CircleCI again to see if there was an intermittent issue.
However, there is a difference in text coloring between the two. I find the use of red and green in CircleCI to highlight the errors significantly beneficial. Looking through the logs on GH Actions takes me a lot more effort than it does on CircleCI. Is there a way we can get the errors a particular color (e.g. red)? On CircleCI it's very fast to focus on the errors, but on GH Actions, I actually have to parse most of the text, rather than just focus on the errors.
@thesecretmaster I wasn't focusing on the fact that there were errors to resolve. I was trying to focus on the difference of which errors showed up vs. which passed on the same commit, along with the visual presentation.
I'd assume there was a color config option, I just haven't dug into it.
[ SmokeDetector | MS ] Bad ip for hostname in body, bad keyword in body, blacklisted website in body, link at end of body, pattern-matching website in body, +1 more (490): suitable for every human being by dishedvonke on superuser.com
@Makyen That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer; append -force if you really want to do that.
@RyanM That would be a reasonable thing to exclude when you haven't given MS write permissions. OTOH, I know it doesn't show up everywhere I'd want to use it. However, I'm not remembering the exact criteria that's used.
@SmokeDetector tpu- Every single one of this person's four answers (or a self-comment below the answer) links to loginradius.com. Flagged this as spam since it's non-responsive and sent a custom mod flag on another.
@CodyGray It's fairly formulaic for that type of watch. I also wrote a script that does some of the formatting, but not all, and not as much as I 'd like yet.
@CodyGray :) If it's possible to reduce repetitive tasks, I'm a fan of automating it, as long as it doesn't remove the human element, where that's needed.
Was just reading someone earlier today in chat saying that something could be done/maintained manually, and thinking, well, we're programmers, so that's not likely to be the solution we'll arrive at.
Ah... no. That doesn't sound like the right solution. Sure, sometimes it is, but usually automating, at least some parts, has significant benefits, as long as you're going to be doing it multiple times.
It was Catija, and we were talking about Sam could fix his Election bot's user list (chat.stackoverflow.com/transcript/message/49843775#49843775). I chuckled because I was just thinking, yes, that's how normal humans would handle this, but we are programmers. Stand back!
Sure, if you only wanted it for SO, or only wanted it to work once, maybe it would be reasonable to just manually update it now, but you'll save additional work later and be closer to something other sites can use if it's automated.
@iBug You'll need to ask @Undo or @ArtOfCode to do that. There are others that could do it, but Art and Undo are the ones which are most likely to take that on.
[ SmokeDetector | MS ] Bad keyword in body, blacklisted website in body, pattern-matching website in body, potentially bad ip for hostname in body, potentially bad keyword in body (292): daklinrapudsdssfsfs by daklinrapu on askubuntu.com
@Daniil That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer; append -force if you really want to do that.
[ SmokeDetector | MS ] Blacklisted website in body, potentially bad ip for hostname in body, potentially bad keyword in body, blacklisted user (172): How To Scrape Google Maps Reviews? by Harry on softwareengineering.SE
