<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cli on funinkina's corner</title><link>https://funinkina.co.in/tags/cli/</link><description>Recent content in Cli on funinkina's corner</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 16 May 2026 00:09:59 +0530</lastBuildDate><atom:link href="https://funinkina.co.in/tags/cli/index.xml" rel="self" type="application/rss+xml"/><item><title>Deadenv</title><link>https://funinkina.co.in/projects/deadenv/</link><pubDate>Sat, 16 May 2026 00:09:59 +0530</pubDate><guid>https://funinkina.co.in/projects/deadenv/</guid><description>&lt;p&gt;Every developer I know has a &lt;code&gt;.env&lt;/code&gt; file they shouldn&amp;rsquo;t. Maybe it has a production API key. Maybe it&amp;rsquo;s tracked in git with a &lt;code&gt;.gitignore&lt;/code&gt; entry that someone forgot to add. Maybe it&amp;rsquo;s just sitting there, world-readable, on a shared dev machine. We all know it&amp;rsquo;s bad. We keep doing it anyway because there&amp;rsquo;s no real alternative that doesn&amp;rsquo;t add significant friction.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;deadenv&lt;/code&gt; is my attempt to fix that. It&amp;rsquo;s a cross-platform CLI tool written in Go that stores secrets in the OS-native keychain: Keychain on macOS, libsecret/GNOME Keyring on Linux, Credential Manager on Windows, and injects them into subprocesses at runtime. Secrets never touch the filesystem in plaintext.&lt;/p&gt;</description></item></channel></rss>