> Bad ip for hostname in body, bad ip for hostname in title, blacklisted website in body, blacklisted website in title ---------- Bad ip for hostname in body - aiobjectives.com suspicious IP address 162.241.216.230 Bad ip for hostname in title - aiobjectives.com suspicious IP address 162.241.216.230 Blacklisted website in body - Position 0-16: aiobjectives.com Blacklisted website in title - Position 0-16: aiobjectives.com
@iBug This change will cause CRLF/LF problems, because it forces SD to not account for the files being properly checked in and out of Git in the native format. What current issue was this change intended to solve (a current issue is implied by your statement of frustration and making a change)?
As far as I know, SD has been running properly wrt. using CRLF/LF line endings for the last four months. Are there recent issues? The only significant CRLF/LF issues I'm aware of were back in August. The problems, which existed back then for a short time and on only a few commits, were resolved.
The underlying issues were: A) On Windows, SD was using a git which wasn't correct for the architecture; now guarded against by SD aborting if it detects it's using the wrong git version, and B) that Git had been explicitly told not to treat the blacklist text files as text, which caused Git to incorrectly preserve the line endings, as if they were binary files. The .gitattributes file was adjusted to define the blacklist/watchlist files as text, so Git properly handles CRLF/LF conversion.
Basically, with this most recent change, if the files are correctly checked out of Git and properly converted to CRLF/LF for the local architecture, your are forcing SD to use the wrong line endings, if it's running on a system that natively uses CRLF.
On systems that natively use CRLF, this will A) cause SD to incorrectly add a CR onto every pattern when it reads the file, and B) will result in SD writing lines with only a LF, which Git may, or may not, properly convert when the files are checked back in.
The git blame issues I'm aware of are residual issues resulting from a few changes in CRLF/LF on the blacklist files back in August, but making this current adjustment to how SD opens files isn't going to resolve the existing issues with the history. The only thing which would repair the git blame issues I'm aware of would be to rewrite the history in Git of the affected files, which this doesn't do. Rewritting the history has it's own issues, so hasn't been done.
So, basically, have you been seeing current issues with how CRLF/LF line endings are being handled on the blacklist files? If so, please point me to a couple of commits so I can see what's happening.
#advertising seems to contain a lot of junk, all spam is in some sense advertising but I would expect the tag to contain spam about advertising, i.e. copywriting, ad placement services, etc
@iBug For now, I've reverted this change. The choice was either revert the commit or take my Windows based instance offline. Given our current lineup of SD instances, I don't really see forcing that instance offline as an option.
@iBug I'm not really sure what you're trying to achieve with the change. If properly checked out, the files exist on the local machine in the local machine's native line ending format. Forcing SD to read it as other than the native format will result in errors while reading it in. If SD then writes in the non-native format, then some of the lines in the file will have one type of line ending and some will have another.
Is there some current problem you're having that you're trying to solve?
@Makyen If a currently-blacklisted website is being used in the same copypasta as a new website (indeedgold vs indeedmoney; see this search), would that count as "ongoing campaign"?
@Das_Geek that sounds like a strong clue to conclude that they are; but we try to avoid hard and fast rules so additional evidence would always be welcome
yeah, I was vaguely thinking along the same lines but never sat down to look for a good pattern
let's just see how it performs, it's an excellent watch in any event but the lack of TPs so far is not in and of itself convincing until we see that it doesn't easily trigger on common phrases used by legitimate users
@Das_Geek That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body; append -force if you really want to do that.
@Das_Geek git pull has failed. This shouldn't happen. Details have been logged.
@double-beep FYI: SD CI runs on both Circle CI and Travis. The two use different Python versions to test for compatibility across different versions of Python 3.
[ SmokeDetector | MS ] Link at end of answer, potentially bad keyword in answer, potentially problematic ns configuration in answer, username similar to website in answer (121): Implementing fluid JS tile interface by Helo Plus on stackoverflow.com
@double-beep SD runs CI on both Travis CI and Circle CI. While Travis has since moved to VM-only, Circle still provides container-based environments which are both fast-starting and fast-executing (CPU on Circle appears to be more powerful). So MS listens on Circle for CI notification, and as soon as Circle passes, the revision is considered "good to pull".
GH Actions, OTOH, judging from my own experiences, is VM-based yet starts instantly (pooling maybe). However because we already have two platforms running two different Python versions (Circle - mainstream, Travis - oldest compatible), we're currently seeing GH Actions less helpful until we can utilize its variety of OS platforms, particularly macOS and Windows, which aren't easily available on the two existing CI platforms.
@ArtOfCode Only the admin API key (for updating indices with jekyll-algolia). BTW, MS needs some patches as well so it could start an extra workflow whenever Smokey or MS wiki is edited.
Would linking at the end of your post(s) to your youtube channel (or playlist on it) be considered spam? Or if the playlist has relation to the topic then it's ok?
@MartinSleziak An isolated occurrence would not alone make it spam if the link is relevant and helpful (and with proper disclosure of affiliation), but repeated offenses are generally not tolerated.
@MartinSleziak Yes, it is considered spam. Linking to something you are affiliated with without disclosing the affiliation in the post is considered spam. Over promotion is also considered spam, but is more of a judgement call. However, I would suggest using a custom mod-flag for those, rather than red-flagging.
@SmokeDetector fp- The user is asking about a pentesting capture-the-flag machine distributed on that website. It's also on VulnHub, so I'd guess it's legit.
@Machavity That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body; append -force if you really want to do that.
@Makyen really? it matches the case here. I believe telegram usernames are generally @userName or similar; nothing comes before the @, so the \b should work just fine
@Makyen When watching numbers, should I omit the country code like that?
@Das_Geek That "nothing" is a space, which is included in \W. @ is also in \W. A \b is the transition between \W and \w, or the reverse direction (or, depending on regex implementation, a \w to/from ^ or $). Without a \w prior to the @ in the string to be tested the \b won't match, so the regex won't be looking for a @ in that spot (i.e. that regex won't match in our environment). The tested text would need to be something like foo@greatOwen for that regex to match.
To do what you want, you could use a regex like greatOwen(?<=@greatOwen). You could shorten the number of characters used in the regex to g(?<=@g)reatOwen. However, the shorter version costs more CPU time in the much more likely case of a non-match, and isn't as easily readable for a human looking at the regex. Thus, my preference is the longer version.
