<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: barco</title><link>https://news.ycombinator.com/user?id=barco</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Tue, 14 Apr 2026 09:58:40 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=barco" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by barco in "Debugging an Undebuggable App"]]></title><description><![CDATA[
<p>Does iOS have something like PTRACE_SYSCALL to hook up on syscalls entry and maybe change the return value? (Or detect where the SVC is being made)</p>
]]></description><pubDate>Mon, 17 Feb 2025 22:28:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=43083902</link><dc:creator>barco</dc:creator><comments>https://news.ycombinator.com/item?id=43083902</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43083902</guid></item><item><title><![CDATA[New comment by barco in "Anyone can access deleted and private repository data on GitHub"]]></title><description><![CDATA[
<p>I reported a variant of this issue that (to me) was unexpected:<p>* You add someone to your private repo.<p>* After some time, you revoke their access.<p>As long as they keep a fork (which you can't control) they can use this same method to access new commits on the repo and commits from other private forks.<p>Back in 2018, this was a resolved as won't fix, but it also wasn't documented.</p>
]]></description><pubDate>Thu, 25 Jul 2024 13:58:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=41068774</link><dc:creator>barco</dc:creator><comments>https://news.ycombinator.com/item?id=41068774</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41068774</guid></item><item><title><![CDATA[New comment by barco in "Address Sanitizer Internals"]]></title><description><![CDATA[
<p>There are multiple versions of HWAsan.<p>One for ARMv8 with Top-Byte-Ignore: you can use the top byte of memory addresses to store a tag.<p>When you allocate memory you return  the "tagged" pointer and internally store "this region has this tag".<p>When you dereference a pointer, you check that the tag matches what you expect in your internal data structure.<p>With memory tagging extensions you can do something similar but the checks are performed by the processor.</p>
]]></description><pubDate>Sat, 15 Jun 2024 21:52:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=40692957</link><dc:creator>barco</dc:creator><comments>https://news.ycombinator.com/item?id=40692957</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=40692957</guid></item><item><title><![CDATA[New comment by barco in "Automated Unit Test Improvement Using Large Language Models at Meta"]]></title><description><![CDATA[
<p>If you name it `NUMBER_ELEMENTS_AVERAGED`, then when you add a new element to average, you will miss the fact that you also need to modify that value :)<p>You either have them on a list and calculate it dynamically based on the size, or have it as a magic number.</p>
]]></description><pubDate>Sat, 17 Feb 2024 14:52:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=39409933</link><dc:creator>barco</dc:creator><comments>https://news.ycombinator.com/item?id=39409933</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39409933</guid></item><item><title><![CDATA[New comment by barco in "Tell HN: GitHub will delete your private repo if you lose access to the original"]]></title><description><![CDATA[
<p>Given the nature of super forks in GitHub, if you are no longer a contributor, but keep your fork, you would be able to see the commits that happen in the original repo and all its forks.<p>There used to be a way to bypass the deletion, which was to clone into a organization. That way, GitHub would not delete your fork. I am not sure if it is still the case.<p>I reported all this to GitHub a few years ago, but they said it was a non-issue .</p>
]]></description><pubDate>Wed, 01 Feb 2023 01:37:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=34605146</link><dc:creator>barco</dc:creator><comments>https://news.ycombinator.com/item?id=34605146</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=34605146</guid></item><item><title><![CDATA[GitHub lets users access private repos after they have been kicked out]]></title><description><![CDATA[
<p>Article URL: <a href="https://www.reddit.com/r/programming/comments/airtdw/its_possible_to_access_private_github_repos_after/">https://www.reddit.com/r/programming/comments/airtdw/its_possible_to_access_private_github_repos_after/</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=18975216">https://news.ycombinator.com/item?id=18975216</a></p>
<p>Points: 2</p>
<p># Comments: 0</p>
]]></description><pubDate>Wed, 23 Jan 2019 02:46:41 +0000</pubDate><link>https://www.reddit.com/r/programming/comments/airtdw/its_possible_to_access_private_github_repos_after/</link><dc:creator>barco</dc:creator><comments>https://news.ycombinator.com/item?id=18975216</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=18975216</guid></item><item><title><![CDATA[New comment by barco in "Unix Syscalls"]]></title><description><![CDATA[
<p>In x86 and x86_64 it doesn't matter whether the caller has control or not over the return address, because there's a change of privilege when the kernel returns from the interrupt (IRET instruction). So at that point it would be equivalent for the userspace app to just jump to whatever address it wants.<p>The caller does not have control over the return address. When int n or syscall instructions are executed, it's the processor who pushes the current context onto the kernel stack (pointed by ss0:esp0), so when you run iret, everything will go back to normal.<p>Even if the caller had control over this return address, the CR3 does not change [without taking KPTI into consideration], so the memory mappings will still be the same, and everything would be handled with paging enabled, so there's no "arbitrary physical address". You would only be allowed to jump to anything that you have already mapped, and given that there's a privilege change, you would only be able to access userspace memory.<p>This has nothing to do with whether the syscall parameters are passed down the stack or not. In x86 and x86_64, when you make a syscall and the kernel handles it, the stacks change, so if you were to pass parameters via the stack, you would need to be able to access the userspace stack from the kernel and it sounds like a mess (but possible). The registers, on the other hand, are available for the syscall handler to use, so it's easier to just set the parameters there.</p>
]]></description><pubDate>Wed, 08 Aug 2018 05:20:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=17713376</link><dc:creator>barco</dc:creator><comments>https://news.ycombinator.com/item?id=17713376</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=17713376</guid></item></channel></rss>