mukesh610

From the README:

A sync process syncs the open disk files once every config.syncInterval. Sync also can be done on every request if config.alwaysFsync is True.

Ah, failed to notice that.

I was so excited because this was exactly what I coded up today, I jumped straight to the comments.

I built this very same thing today! The only difference is that i pushed the tool call outputs into the conversation history and resent it back to the LLM for it to summarize, or perform further tool calls, if necessary, automagically.

I used ollama to build this and ollama supports tool calling natively, by passing a `tools=[...]` in the Python SDK. The tools can be regular Python functions with docstrings that describe the tool use. The SDK handles converting the docstrings into a format the LLM can recognize, so my tool's code documentation becomes the model's source of truth. I can also include usage examples right in the docstring to guide the LLM to work closely with all my available tools. No system prompt needed!

Moreover, I wrote all my tools in a separate module, and just use `inspect.getmembers` to construct the `tools` list that i pass to Ollama. So when I need to write a new tool, I just write another function in the tools module and it Just Works™

Paired with qwen 32b running locally, i was fairly satisfied with the output.

Unintentionally discovering a thing you know you're going to hate has got to be top 10 internet experiences.

Even then, use of a DNS CAA record should mitigate this, right?

Both articles are correct, from me reading them. When you invoke a shell script directly, it gets passed to the kernel to try and execve. The kernel returns ENOEXEC when it detects it doesn't have a shebang. The shell catches the error, and then as a last resort, tries opening the file and interpreting its instructions.

I might be wrong, so do correct me if so.

No, in my YAML example, you could see that there were no credentials directly hard-coded into the pipeline. The credentials are configured separately, and the Pipelines are free to use them to do whatever actions they want.

This is how all major players in the market recommend you set up your CI pipeline. The problem here lies in implicit trust of the pipeline configuration which is stored along with the code.

You're right, there are other avenues of exploitation. This particular approach was interesting to me because it is easily automatable (scour the internet for exposed credentials, clone the repo and detect if Pipelines are being used, profit).

Other exploits might need more targeted steps to achieve. For example, embedding a malware into the source code might require language / framework fingerprinting.

It's pretty common in systems where the final output to be deployed is the same as the root of the source tree. More often than not, lazy developers tend to just git clone the repo and point their web server's document root to the cloned source folder. In default configurations, .git is happily served to anyone asking for it.

This seems to be automatically mitigated in systems which might have a "build" / "compilation" phase, because for the application to work in the first place, you only need the compiled output to be deployed. For instance, Apache Tomcat.

Don't use this. I once tried it and it changed the UUID of the Linux partition without any warning. Grub was unable to pick up the partition and boot, so I was stuck at grub rescue.

God knows what other bugs their software has.

Not exactly sure how streamlined your security process is, but for some orgs it is a red tape roller coaster to even get one TCP port open.

Anyways, you could also block all traffic to ngrok servers just to ensure your Dev teams aren't skirting around your firewall.

IMO fair use is still not a strong argument for Microsoft. They commercialized the product and made money out of it.

Fair use is only allowed if the work you're doing is purely for the greater good. I might be wrong though, IANAL.

I don't see what your comment is trying to point out.

The same could be said for all the other Secret Scanning partners GitHub has, like AWS and so on.

That being said, it's impossible that a "bad regexp" is gonna make its way to the GitHub codebase.

Detecting GPT generated content will take a fairly large language model to be reliable. Obviously this would need to be run in the cloud. Considering Apple's stance on privacy, sending private correspondence to the cloud is a huge no-no for them. Nobody is gonna implement GPT detection, atleast for emails.

I'm confused. In your first comment you seemed to refer to legitimate sites harvesting credentials using Google SSO (whatever that means)

Now you're talking about phishing sites.

Can you clarify which kind of websites you're referring to?

There's a difference between getting fired and laid off

Fiction isn't exactly a good argument

I'm interested in the thought process that made you conclude that that is the simplest explanation

It depends on which keyboard you're using. I'm using the Google keyboard and it's pretty advanced: i typed this comment with it, and only corrected the word "typed" which showed up as "tired"

I don't see the connection, but I know of a bunch of people who'd be pretty mad about how a corporation can remotely cut off an entire country's digital access.

So right to repair right out of the window?

Why is it "shocking"? Why are you saying "gender-dominated" like it's a bad thing? Which areas are "gender-dominated" that you are upset about?

"Suggested searches" are not ads. I'm pretty sure Google does not financially benefit from a user mis-clicking on suggested searches.

I'd say knowing your IDE well is critical to speeding up your workflow.

I managed to fix three thousand code smells on a very badly written codebase in a span on two days. Thanks IntelliJ IDEA!

Usually, I feel like git is more than enough. But when I have my push rejected because I failed to fetch first, it's just a single click in IntelliJ to fetch, rebase my work on that and push it again.

There's also hub, from GitHub. I find myself using "hub sync" to update all my local branches at once.

I'd say it's a rather insecure platform if it's meant to evade surveillance. In a heavily censored state, the only types of people who'd use this platform are those who are against the state, and if the state gets hold of this application it's pretty easy to find out what's being shared just by walking close to one of the users who are most likely already in a watchlist.

As I've commented elsewhere, DoS can be easily mitigated by implementing another layer with basic object recognition to filter out false positive collisions.

> For example you wouldn't know if a kind of steganography has been used to hide image in an image and that neuralhash picked on a hidden image.

How would NeuralHash pick a "hidden image"? It only uses the pixels of the image to get the hash. Any hidden image in the metadata would not even be picked up and no amount of steganography can fool NeuralHash.

> There is many vectors. For example you can leave phone unattended and someone can snap a picture of an image or since a collision may look innocent to you, you would overlook it in an email etc...

As iterated elsewhere in this thread, random gibberish pixels colliding with CSAM would definitely not be useful in incriminating anyone. The manual process would catch that. Also, if the manual process is overloaded, I'm pretty sure basic object recognition can filter out most of the colliding gibberish .

The same key can be copied over to any number of repos you want, unless I'm missing something from the GitHub docs

You could always use "Deploy keys" which are per-repo read-only SSH keys. You could set up multiple repos with the same deploy key and use the private key in GitHub Actions secrets.