Yeah I have seen this issue a few times. If you use Docker build arguments that way add `--provenance=false` to get rid of all that build metadata. Build secrets are still better since they allow you to scope the secret inside of the Dockerfile. Also, the metadata can be useful to inspect images.
Both of these things are true: commands like diskcopy have special handling to allow the same drive to be used as both source and destination, and the DOS I/O has special handling to request disk changes from A: to B: on single-drive systems for programs that lack specific support.
Swift comes to mind, and this website has more https://opensource.apple.com/projects/ (it lists WebKit, but I guess they count WebKit after it split from KHTML, I’d agree with you there)
Also, Bonjour originated at Apple and it is cross-platform, although Avahi probably is more popular
CUPS is associated with Apple as well, but it seems that it also did not originate there
I was going to say swift, but I figured someone would undercount that because it is so overly relevant as an iOS/Mac development language even though it really is a pretty good portable language. But man... undercounting webkit and clang+llvm is a new level of ignorance..
It is ignorance to call them apple projects when they really aren't. The copyright notice of webkit is full of emails like @kde.org… wonder why it's not entirely @apple.com?
The majority of the advancements done to make the standards compliant browser with great js performance were done at Apple. Going by the copyright notice as the the source of a vast majority of the dev in the 2000s seems pretty special.
Actually the arm64 backend is a grey area. I knew some guys that worked on it in secret at Apple. They definitely created and Developed it at Apple and dropped it on the community after the iPhone 5s launched, replacing the existing aarch64 backend.
I’m not 100% certain if they started with any bits of the previous aarch64 backend or not though.
You need to merge the relevant ignore files to create one specific for you, so if you use VSCode on macOS VisualStudioCode.gitignore (e.g., .vscode) + macOS.gitignore (e.g., .DS_Store). There are files for other OSs and editors as well. Technically their README says that the Global folder is intended for user-specific ignore files. But you can still use them for the repo .gitignore.
Location: Germany (UTC +1/+2), EU citizen
Remote: preferred
Willing to relocate: no
Technologies: C# and previously C++ and Java, prefer functional style and privately dabble with F# and Haskell. I know SQL, Azure, Docker, high performance computing (Monte Carlo simulations), see also CV
CV: https://stash.ldr.name/wwtbh/rcv-202609-vfay7k0zano.pdf
Email: see CV
I work in mathematical finance so a lot of domain knowledge in that area (derivatives, pricing, probability theory).
Yes, I’ve also experienced this kind of attitude. Some scanning tools can detect that certain CVEs do not apply because the specific functionality is not used.
I hope your team was OK with you uninstalling the VMware package manually (this is actually not a bad outcome if you don’t use that package)
There are also ridiculous CVEs like CVE-2018-20225 for pip, which will not get fixed as that behaviour is by design (but here as well it might be a good idea to strip pip if it’s not used)
> An issue was discovered in pip (all versions) because it installs the version with the highest version number, even if the user had intended to obtain a private package from a private index.
To be fair this behavior + extra-index-url definitely allowed for dependency confusion attacks. Now it's a bit silly for the CVE as written, but IIRC this was before you could use index-url to point exclusively to an internal package host so there were (and in other ecosystems still are) dependency confusion attacks going on in the wild where attackers are publishing "internal-package-a@999.9.9" on any public package host (NPM, PyPi, etc) to try to compromise companies that have internal packages of the same name.
For the attack you mentioned (reusing internal packages in a public repository) prefix reservation is one possible solution. Unfortunately PyPI does not support it.
I don't understand what's ridiculous about that pip CVE, could you explain? Just because something is by design that doesn't mean it's not a vulnerability or somehow unexploitable.
Maybe I was too harsh. It’s the CVE in conjunction with its high severity, the maintainers’ decision and the bundling of pip with CPython. In the end what can you do about it as a dev given that the pip maintainers have decided not to fix it? The only option is not to use pip at all (and sure, you can see the CVE as a critique of pip in a way), or discuss with your security team in hope for some exclusion. And since pip or at least ensurepip are part of Python you get a lot of these scan results
E: and if you decide not to use pip I don’t think there’s an official way to remove ensurepip, I typically rm -rf inside of site-packages, it works but doesn’t feel correct
The CVE looks relevant to me. If you're trying to get a package from a private repo, and someone publishes version 999 of that package on a public repo, then you're executing their code instead of your own. Just because the pip maintainers refuse to fix it doesn't mean it isn't a security vulnerability that could lead to remote code execution and needs to be controlled for in some other way.
One could argue that this is not an issue with pip, the software, but of the index used. I mean, if you control both index and extra-index there is no problem (and one solution to this is to use your own mirror with a set resolution order). This could very well be addressed in PyPI, for example NuGet allows to reserve package prefixes.
We also do not create a CVE for curl because you can use it to download the wrong bash script. If this was an alert for suspicious usages of pip instead of pip itself, I’d be less critical of it.
One could argue that, certainly, but I think it's a little disingenuous. Pip makes it impossible to use extra-index-url safely, in the ~only use-case that option has. There is no world where you use extra-index-url and you're not vulnerable in some way or another to dependency confusion.
In other videos Casey argues against the profile–fix–repeat workflow (I’m not saying that you necessarily meant this by measuring), instead arguing for estimating the theoretical maximum, then trying to get close enough to it. His argument is that the former might push you towards a local minimum without realising that you could do much better
When "Estimating the theoretical maximum" you're going to bring your assumptions to that estimate and so you're equally likely to get stuck in some local optimal point because you didn't see what else was possible, so that doesn't persuade me much. Worse, now it's a local optimal which might be entirely in your head.
There is some space for this "Estimate the theoretical maximum" as a high level insight, if the software needs to do a thing which your estimate says is impossible that's important to address up front but I think for practical software engineering you're much more likely to need profile-fix-repeat
Actually measuring is crucial and an estimate is not a measurement. I think one of the reasons many in the Handmade Community don't like measuring is that it too often ruins their "estimate" of how the crap they've written is achieving a "theoretical maximum" in favour of a boring fact that it's much worse than alternatives.
Usually the ideas it that the theoretical maximum is not a local optima though, but some ideal global optima which you know you realistically cannot reach.
That is you know the data is some size, and memory throughput is some rate, and clock cycles is some rate etc...
You are entirely correct about the line of thinking if your assumptions are down a different line of thinking such as algorithmic estimates though, where you might miss some better way of doing things.
I've always used this method of working and can stand by it. For instance let's say you are working on a high-speed real-time image processing system. If you know that each image is 1080p for instance, that's 2 million pixels, and we will have 3 bytes per pixel for colour, then that's like 6MB per image (without compression). If you have 25 GB/s of RAM bandwidth, then there is a hard limit of ~4 thousand frames per second if you aren't even doing any processing. Therefore if you strip out your processing and are only getting say 400 frames per second, you know something is going wrong.
This can be applied roughly to anything. I find it very handy when thinking about CPU/GPU performance as well. For instance knowing that at 5GHz you have 5 billion clock cycles per second, which depending on instructions and pipe lining etc... can be roughly 5-30 billion operations per second per core tells you how long some process should take if you know roughly how many operations are required and the data size you are operating on.
Obviously as you drill down things get much more complicated, but they give you some rough idea about how fast things could be under some set of assumptions. Very similar to how a physicist works with models and assumptions.
Aren’t the shortcuts with the command key older than the PC ones (which started out as Shift+Insert etc. actually)? I wouldn’t call that desire to be different (also as mentioned below it has a lot of advantages in a terminal)
I’ve always used Ctrl+U, it’s an Emacs shortcut, so it works in many shells and other prompts (especially since readline supports it) by default.
(For example Ctrl+Opt+- doesn’t seem to work in the Python REPL whereas Ctrl+U does.)
reply