Monthly Archives: December 2014

Episode #180: Open for the Holidays!

Not-so-Tiny Tim checks in with the ghost of Christmas present:

I know many of you have been sitting on Santa's lap wishing for more Command Line Kung Fu. Well, we've heard your pleas and are pushing one last Episode out before the New Year!

We come bearing a solution for a problem we've all encountered. Ever try to delete or modify a file and receive an error message that the file is in use? Of course you have! The real problem is trying to track down the user and/or process that has the file locked.

I have a solution for you on Windows, "openfiles". Well, sorta. This time of year I can't risk getting on Santa's bad side so let me add the disclaimer that it is only a partial solution. Here's what I mean, let's look for open files:

C:\> openfiles

INFO: The system global flag 'maintain objects list' needs
to be enabled to see local opened files.
See Openfiles /? for more information.

Files opened remotely via local share points:

INFO: No shared open files found.

By default when we run this command it gives us an error that we haven't enabled the feature. Wouldn't it be nice if we could simply turn it on and then look at the open files. Yes, it would be nice...but no. You have to reboot. This present is starting to look a lot like a lump of coal. So you need know that you will encounter the problem before it happens so you can be ready for it. Bah-Humbug!

To enable "openfile" run this command:

C:\> openfile /local on

SUCCESS: The system global flag 'maintain objects list' is enabled.
This will take effect after the system is restarted.

...then reboot.

Of course, now that we've rebooted the file will be unlocked, but we are prepared for next time. So next time when it happens we can run this command to see the results (note: if you don't specify a switch /query is implied):

C:\> openfiles /query

Files Opened Locally:

ID Process Name Open File (Path\executable)
===== ==================== ==================================================
8 taskhostex.exe C:\Windows\System32
224 taskhostex.exe C:\Windows\System32\en-US\taskhostex.exe.mui
296 taskhostex.exe C:\Windows\Registration\R00000000000d.clb
324 taskhostex.exe C:\Windows\System32\en-US\MsCtfMonitor.dll.mui
752 taskhostex.exe C:\Windows\System32\en-US\winmm.dll.mui
784 taskhostex.exe C:\..\Local\Microsoft\Windows\WebCache\V01tmp.log
812 taskhostex.exe C:\Windows\System32\en-US\wdmaud.drv.mui

Of course, this is a quite long list. You can use use "find" or "findstr" to filter the results, but be aware that long file names are truncated (see ID 784). You can get a full list by changing the format with "/fo LIST". However, the file name will be on a separate line from the owning process and neither "find" nor "findstr" support context.

Another oddity, is that there seems to be duplicate IDs.

C:\> openfiles /query | find "888"
888 chrome.exe C:\Windows\Fonts\consola.ttf
888 Lenovo Transition.ex C:\..\Lenovo\Lenovo Transition\Gui\yo_btn_g3.png
888 vprintproxy.exe C:\Windows\Registration\R00000000000d.clb

Different processes with different files, all with the same ID. This means that when you disconnect the open file you better be careful.

Speaking of disconnecting the files, we can do just that with the /disconnect switch. We can disconnect by ID (ill advised) with the /id switch. We can also disconnect all the files based on the user:

C:\> openfiles /disconnect /a jacobmarley

Or the file name:

C:\> openfiles /disconnect /op "C:\Users\tm\Desktop\wishlist.txt" /a *

Or even the directory:

C:\> openfiles /disconnect /op "C:\Users\tm\Desktop\" /a *

We can even run this against a remote system with the /s SERVERNAME option.

This command is far from perfect, but it is pretty cool.

Sadly, there is no built-in capability in PowerShell to do this same thing. With PowerShell v4 we get Get-SmbOpenFile and Close-SmbOpenFile, but they only work on files opened over the network, not on files opened locally.

Now it is time for Mr. Scrooge Pomeranz to ruin my day by using some really useful, built-in, and ENABLED features of Linux.

It's a Happy Holiday for Hal:

Awww, Tim got me the nicest present of all-- a super-easy Command-Line Kung Fu Episode to write!

This one's easy because Linux comes with lsof, a magical tool surely made by elves at the North Pole. I've talked about lsof in severalotherEpisodesalready but so far I've focused more on network and process-related queries than checking objects in the file system.

The simplest usage of lsof is checking which processes are using a single file:

# lsof /var/log/messages
rsyslogd 1250 root 1w REG 8,3 13779999 3146461 /var/log/messages
abrt-dump 5293 root 4r REG 8,3 13779999 3146461 /var/log/messages

Here we've got two processes that have /var/log/messages open-- rsyslogd for writing (see the "1w" in the "FD" column, where the "w" means writing), and abrt-dump for reading ("4r", "r" for read-only).

You can use "lsof +d" to see all open files in a given directory:

# lsof +d /var/log
rsyslogd 1250 root 1w REG 8,3 14324534 3146461 /var/log/messages
rsyslogd 1250 root 2w REG 8,3 175427 3146036 /var/log/cron
rsyslogd 1250 root 5w REG 8,3 1644575 3146432 /var/log/maillog
rsyslogd 1250 root 6w REG 8,3 2663 3146478 /var/log/secure
abrt-dump 5293 root 4r REG 8,3 14324534 3146461 /var/log/messages

The funny thing about "lsof +d" is that it only shows you open files in the top-level directory, but not in any sub-directories. You have to use "lsof +D" for that:

# lsof +D /var/log
rsyslogd 1250 root 1w REG 8,3 14324534 3146461 /var/log/messages
rsyslogd 1250 root 2w REG 8,3 175427 3146036 /var/log/cron
rsyslogd 1250 root 5w REG 8,3 1644575 3146432 /var/log/maillog
rsyslogd 1250 root 6w REG 8,3 2663 3146478 /var/log/secure
httpd 3081 apache 2w REG 8,3 586 3146430 /var/log/httpd/error_log
httpd 3081 apache 14w REG 8,3 0 3147331 /var/log/httpd/access_log

Unix-like operating systems track open files on a per-partition basis. This leads to an interesting corner-case with lsof: if you run lsof on a partition boundary, you get a list of all open files under that partition:

# lsof /
init 1 root cwd DIR 8,3 4096 2 /
init 1 root rtd DIR 8,3 4096 2 /
init 1 root txt REG 8,3 150352 12845094 /sbin/init
init 1 root DEL REG 8,3 7340061 /lib64/
init 1 root DEL REG 8,3 7340104 /lib64/
# lsof / | wc -l

Unlike Windows, Linux doesn't really have a notion of disconnecting processes from individual files. If you want a process to release a file, you kill the process. lsof has a "-t" flag for terse output. In this mode, it only outputs the PIDs of the matching processes. This was designed to allow you to easily substitute the output of lsof as the arguments to the kill command. Here's the little trick I showed back in Episode 22 for forcibly unmounting a file system:

# umount /home
umount: /home: device is busy
# kill $(lsof -t /home)
# umount /home

Here we're exploiting the fact that /home is a partition mount point so lsof will list all processes with files open anywhere in the file system. Kill all those processes and Santa might leave coal in your stocking next year, but you'll be able to unmount the file system!


Wow, it's been a awhile since i haven't written anything new here...
So to answer many questions.. no i'm not dead, and will try to get active again a bit next year.

I'm not writing this due to explanation requests or people worried (even if i got solicited many time to write something) but more because i'm motivated again to write.
As i've said many times to the recurrent e-mails i receive and continue to receive (even after 7 months of inactivity!)
I've did a lot of changement in my life, and during this time i got better things to do than writing in a blog.
Principaly i had many personal issues to resolve.
It's also not the first time i repeat that i've a life and that i've always run this blog for fun and nonprofit like my other services such as
And sooner or later i will get bored and do a break although i've continued to update CCT, to don't leave people with nothing.

I changed of job also and shifted in the energy sector.
I wanted to get a job who combine my passion for mechanic and electronic.
And now i'm winding turbo-alternators for nuclear/hydraulic power plants around the world and governmental organisations. (pretty cool, huh?)
I can't tell you details obviously due to confidentiality clauses as it's critical, but making those huge machines/projects are quite awesome and the job is very meticulous.

I've joined also the administration of my local hackerspace, and now holds the position of treasurer.
I'm doing also various workshops mostly electronic/borderline related who take me time to prepare and organize.
In parallel i experiment myself also a lot, those who follow my youtube/twitter activity probably know what i mean, i received 2 day ago hydrofluoric acid.

2014 started a bit bad for me as i had a car crash the day of christmas and got the clavicle broken. Anyway globally it was a nice year, and off my blog i've met a lot of people like Horgh and many others.
Sadly i wasn't able to go to BotConf neither DahuCon this year due to my job... so maybe next year !

I've worked a bit also with Hackerstrip and released recently some codes for DarK-CodeZ #6, nothing fancy but it was fun to participate, thanks guys.
So that all, see you in 2015 for throwing cobblestones and breaking bones !

When the Press Aids the Enemy

Let's start with this- Freedom of the press is a critical part of any free society, and more importantly, a democratically governed society.

But that being said, I can't help but think there are times when the actions of the media aid the enemy. This is a touchy subject so I'll keep it concise and just make a few points that stick in my mind.

First, it's pretty hard to argue that the media looks for ever-more sensational headlines, truth be damned, to get clicks and drive traffic to their publication. Whether it's digital or actual ink-on-paper sensationalism sells, there's no arguing with that.

What troubles me is that like in the war on terrorism, the enemy succeeds in their mission when the media creates hysteria and fear. This much should be clear. The media tend to feed into this pretty regularly and we see this in some of the most sensational headlines from stories that should told in fact, not fantasy.

So when I came across this article on Buzzfeed called "The Messy Media Ethics Behind the Sony Hacks" it suddenly hit me - the media may very well be playing perfectly into the enemy's hands. The "Guardians of Peace" (GOP) in their quest to ruin Sony Pictures Entertainment have stolen an unfathomable amount of information. As Steve Ragan who has repeatedly written on about this and many other breaches tweeted that's 200Gb or 287,000 documents. That's mind-blowing.

This cache of data has proven to be yet-unreleased movies, marketing presentations, email exchanges between executives and attorneys, financial plans, employees' medical records and so much more. The GOP have made it clear their aim is to "punish" Sony Pictures Entertainment - and while we don't really have an insight as to the true motivations here, I think it's clear that releasing all this data is meant to severely negatively impact the business.

What has followed in the days since the announcement of the hack is a never-ending stream of "news" articles that I struggle to understand. There were articles like this one providing commentary and analysis on internal marketing department presentations. There were articles analyzing the internal and privileged (as far as I know, but I'm not a lawyer) communications between corporate legal counsel and Sony Pictures executives. There were articles talking about the release of SPE employee medical records. The hit-parade goes on and on... and I'm not linking over to any more of the trash because it embarrasses me.

Clearly, clearly, the mainstream media (and hell even the not-so-mainstream) have long lost their ethics. Some would claim that it's the "freedom of the press" that allows them to re-publish and discuss sensitive, internal documents. Others argue that since it's already in the public domain (available on BitTorrent) then it's fair game. Note: This was discussed during the Snowden release - and it was clear that classified information released to the public domain does not suddenly lose its classified status. I'm fairly certain this easily applies to the not-national-security type of assets as well. To be honest, this argument makes me question the intellectual integrity of some of the people who make it.

Anyway, back to my point. If the GOP wanted to destroy Sony Pictures Entertainment then hacking in and releasing secret information and intellectual property was only half the battle. The second half, unfortunately, is being picked up and executed by the media, bloggers, and talking heads putting out "analysis" on all this data. Publishing links to the hacked data, analyzing its contents, and looking for further embarrassing and ugly things to publish- the media should be ashamed of itself.

The hack alone wasn't going to damage SPEs image to where it has fallen now - the media is clearly complicity in this and it's a shame. I'm not an attorney so I question whether publishing and discussing confidential communications between an attorney and executive is ethical. Forget that, is it even legal? Journalists and bloggers continue to hide behind the "freedom of the press", and some folks even to blasting me for daring to question the absolute rights of the press. Except - the freedom of the press isn't absolute, as far as I know.

But whether it's legal, clearly there are ethical problems here. If you're in the media and you're poring over the confidential email communications stolen from Sony Pictures Entertainment systems, I emphasize stolen, and you're commenting on this - to what end? Arguing that the media is releasing this information because (a) it's already in the public domain and (b) it's "for the public good" is ludicrous.

Remember - while you're reveling in someone else's misery that you too may be a coincidental victim one day. Then it'll be your turn to have your private information released and analyzed and attacked as part of the next breach. Your recourse? None... Glass houses, journalists. Glass houses.

Sony Pictures – Lessons From a Real Worst-Case Scenario

There is a lot of junk floating around on the Internet and in the media regarding the Sony Pictures breach. Who did it? What were the motives? These are all being violently discussed in the Twitter-sphere and elsewhere, and if you happen to read the articles and blogs being churned out by the media your head is probably spinning right now.
While I don't think we (the public) generally know enough to be able to talk about the breach with any certainty yet - and perhaps we never will - there is an critical point here which I think is being missed.

What is the lesson the public should take away from the breach, and subsequent consequences?

Why nearly everyone has focused on the circus surrounding the breach itself - including the celebrity dirty laundry going public, un-released movies being leaked to bit torrent download sites, and the truckload of everything you never want to get out that's been dumped to the Internet - there is very little focus being given to the thing (or things) that we should all be taking away from this breach.

By now everyone should agree breaches are inevitable, and continuing to pour money into the black hole that is prevention is ridiculous. Let me be clear, I'm not saying to spend nothing on prevention, I'm simply pointing out the continuing folly of pouring ever more money and resources into prevention which we know will fail. So this can't be the lesson.

We all also know that segmentation of duties, data and processes should be a key point in every security program. We've been learning this lesson for almost 20 years now - and I can't help but feel that this push to an even faster delivery of IT services has made segmentation and segregation a near impossibility in  many large enterprises. I've watched CISOs try to leverage tools, network architectures, system re-designs and even cloud services -- much in vain as the result is data, processes and duties of all levels of risk end up in a big free-for-all. So, again, this isn't the lesson to learn.

Should the lesson be that we much not poke the bear? I mean, let's face it, if you look at this objectively outside the limited American viewpoint - Sony Pictures did antagonize North Korea quite a bit. Then again, recent information  made public by the Federal Bureau of Investigation (FBI) has indicated that North  Korea was in fact not the perpetrator of this breach. So maybe poking the bear isn't the problem, and anyway this is a lesson we as humans should learn in Kindergarten not in the corporate world.

So if you're still reading then like me you may be searching for a so what? moment. And to be honest, I am struggling to  provide one. So maybe it's not one thing that we need to learn but a much bigger set of things together. Maybe it's a lesson in humility, communications, planning, execution, operational efficiency, and crisis response all rolled into a heaping pile pushed down the hill and lit on fire. Maybe the bigger lesson we need to learn is that it's not one thing that we need to get right - but rather all of them have to just work well together, and be planned, practiced and tuned.

I seriously doubt anyone out there is planning and practicing for the kind of disaster Sony Pictures is facing right now. If every single piece of intellectual and secret property (including employee records, confidential communications, financials of all kinds, and more) you have was made public - where would you start to recover? Getting your IT systems back online is a good start, but that doesn't mean you can recover your business when your employees, partners, vendors, and customers are banging on your door demanding answers and action.

Maybe that's it then, maybe the lesson is that you can't always package up a lesson learned neatly with a bow based on someone's catastrophic incident. I think it's clear we all can be set ablaze in this manner. If it's not then it should be. So the question I pose to you is this - what's your take-away from the Sony  Pictures catastrophe?

As a side note, many people and articles have taken to calling this an "unprecedented" breach. I am inclined to agree but not for the technical reasons that are being rattled off. It's not because the method of attack was novel, or that there was likely an insider, or even the quantity and quality of the assets that were stolen - or heck even that everything is being made public in an embarrassment to the company. No I think this is unprecedented because we're seeing company executives apologizing to political leaders, civil rights activists fanning race-war flames with some of the email content published, and as one article put it "Sony is a pariah in Hollywood" right now. Folks - that's not good. This is a meltdown of a brutal nature the likes I don't believe we've seen before. This is a PR catastrophe.

As always, I'm interested in your thoughts... leave a comment, or hit me on Twitter.

A Breakdown and Analysis of the December, 2014 Sony Hack

Another incredibly far-reaching in-depth compromise of Sony Pictures has happened, this time by a group known as the Guardians of Peace (GOP). The new compromise has all of the excitement of the old events and more, as blaming North Korea for the attack in retaliation to a movie being released by Sony Pictures is all the rage. Risk Based Security has been keeping an updated timeline of the breach, analyzing the leaked documents, and providing links to additional information.

If you are looking for a comprehensive resource on the Sony Hack then please visit the following page:

Is Bigger Budget an Adequate Measure of Security Efficacy?

Bigger budgets - the envy of security professionals and the scourge of CISOs the world over. While we'd all like bigger budgets to make security better within our organizations, getting more money to spend isn't necessarily a harbinger of goodness to come.

Earlier a fantastic conversation broke out on Twitter, where else, and it started with this tweet from Tony Vargas retweeted by Adrian Sanabria:

The conversation got a little snarky about how throwing money at a problem clearly doesn't indicate that it'll get any more attention or be any closer to being solved. I then made a comment about the American budget and how spending more isn't really helping there - OK that's a stretch but the parallels are clear, I think.

Stephen Coplan made an interesting point which I've seen made many, many times - but I believe it to be false:
*point of clarification - Stephen pointed out that he's not implying more money equals more efficacy, and I don't intend to represent his comments as such.

I personally do not believe a bigger budget means anything specifically, so to equate higher budget with more relevance- I believe that to be false. I have personally witnessed first-hand how organizations take budget increases to spend wildly on necessary widgets, and then fail to operationalize. Security isn't about spending more, it never has been. In fact, the rapid increase in spending generally means that something went publicly wrong and the budget-holders are trying to make a public display of their sensitivity to fix the issues. Unfortunately all too often these are simply that - public displays with little follow-through.

I believe that rather than focus on how much more money an organization spends as a measure of their seriousness of addressing security issue, we should be focusing on resources. You see, resources is inclusive of everything necessary including the critical people aspect as well as the widgets and gadgets that come in 1U rack-mountable formats to address the issues. Better security comes from better training of existing resources, more executive backing, better communications, and more operational support. Better security comes from a shift in culture, and a willingness by security professionals to reach to the business side and align better to goals and needs, and the business folks making a concerted and serious effort to understand that security issues and breaches aren't just web site defacements anymore.

Security (or rather the criminal aspect of the game) is big business with highly industrialized and specialized trades and vertical markets. Addressing security as a technology problem will lead to more breaches, more lost revenue, productivity, shareholder value and trade secrets to name a few of the obvious. Security isn't a "their problem" anymore, in fact it never has been.

If you're at all paying attention to the absolute worst-case scenario that Sony Pictures is living through right now (Steve Ragan at CSO is churning out an excellent series on the matter, I highly recommend you give it a read) you are becoming painfully aware that we're past business disruption, web site defacements and DDoS. We're into business destruction of the kind that has the potential to cost a company hundreds of millions of dollars not just today, but for years to come.

What will it take for companies to take security seriously, and how will we measure that jump? I don't think the upward delta in budget size is the only indicator here. I believe we need to look at the overall resource allocation to understand whether security is being addressed as a cultural issue in the company, or whether we're just given more capital to buy shiny widgets with.

In the end, Casey John Ellis had the tweet that made our point eloquently. I think he said it best when it comes to the ability to "buy more stuff" for CISOs, in relation to that making a positive program-level impact on the organization-

...and this, my friends, about sums up my feelings on the matter.

AVbytes Multirogue 2015

This Chameleon fake Antivirus is looking for the OS version (XP, Vista, Seven) and changes its name and skin: AVbytes Win 7 Antivirus 2015, AVbytes Win 8 Antivirus 2015, AVbytes Vista Antivirus 2015, (...). It detects fake infections and displays alert messages to scare users. It belongs to the Braviax/FakeRean family.

When Your Marquee Client Gets Hacked

There are people who will tell you that all PR is good PR. In my years in security I have seen both sides of that debate true. Lately though, particularly for security companies who are selling into the enterprise - this may be a double-edged sword that cuts deep.

Look at any reputable (and some not-so-much) security vendor's website and you'll notice there's always a page that gives you all the different logos of the companies who use their products. Most times the vendor pays dearly for that either through deep discounts, or some other concessions just to be able to use the reference. Generally this works to the vendor's advantage because seeing Vendor X used by your peers means that perhaps it's a good idea to give them a look.

Except, maybe, when those peers are getting hammered for being a data breach victim.

This has happened a few times recently with vendors touting big names as marquee clients- then the marquee client suffers a massive data breach. Interestingly enough, some sales people still use the fact that the client had the product running in their environment to push the sales agenda, but I don't think this is the approach they want.

Think about it.

Your big client gets hit while they're being hailed as using your product or service. Are you sure you want to claim victory? Most of these aren't little incidents, but rather the kinds of breaches that make lawyers cry.

There are two ways this presents itself-

First, your product or service supports either the defense, detection, response or recovery from the attack and subsequent breach. This bodes well, generally. If the organization made the investment in your product or service and you helped them decrease the amount of pain they and their customers have to go through - you win.

Second, your product was a bystander - neither helping nor hurting. This is where things get a little sketchy. Maybe you were sold the "SQL Injection Prevent-o-Matic" but your big e-commerce site was thoroughly ransacked using SQL Injection. There are two sub-plots that you can follow...

If your product or service detected or could have prevented, detected, or helped respond/recover from the attack but no one operationalized your product or service - you're in trouble.

Alternatively, if your product or service completely missed the attack and didn't provide value - you're in trouble.

I've watched companies present marquee customers all the time with little regard for what that means to their corporate brand. "This company just got hacked, true, but our product was right there telling them that they were getting hacked! If only they listened to our amazing product!" is perhaps the worst marketing pitch, ever. You know why? Because you're demonstrating that even though your product could do amazing things for your clients, your failure to teach your clients how to operationalize and be effective with your product at best makes the whole thing a bad investment. At very worse, it makes your product or service crap.

This is why I marvel when I hear that claim made - "They bought our stuff, if only they had used it properly...". It makes me crazy because you're taking a backhanded swipe at your client all while making a clear statement that you were part of the failure.

Folks security kit isn't magic. You don't claim victory by having it dropped off at your dock, or even having it in-line and blinking in your racks. Heck you don't even get credit if the console is up on someones screen. Only when it's fully operationalized do you get to claim credit, in a positive way.

Repeat after me - fully operationalized is how we claim success. I can't stress this enough. It's baffling that vendor and enterprise alike aren't fully getting this in wide adoption. Owning a Formula 1 car doesn't make a winning Formula 1 team. A good pit crew, managers, lots of practice, operational mechanics, management, a driver and good telemetry are just the start of it. Once you get all of the parts together you have to work out bugs until the whole thing is near-perfect. Then you push harder. That's how you operationalize security - otherwise you've failed.

Was the past better than now?

Here we go again — another article arguing whether the past was better or not (this one says “better”). These articles are tiresome, rehashing the debate whether technology is enabling or isolating and dehumanizing. But I’m interested in a different line of technology criticism: which parts of technology are a regression and what to do about that.

From the first stone tools, technology has both reflected us and changed us. When we became farmers, we became less portable and vulnerable to robbers, and it was possible to measure capital for the first time via a land’s quality and location.

When evaluating today’s technology, I think it’s important to keep a flexible point of view and not be limited by a linear view of history. For example, what would digital cash look like today if we had adopted a 10-year land ownership rotation back then? A linear progression from good to bad (or bad to good) ignores a more nuanced view that focuses on the good and bad, leading to an understanding what we can do about it.

Even though I work with developing new technology every day, I’m reticent to adopt it until I have time or motivation to review it thoroughly. There are two main reasons:

  1. Advances in technology often come with critical regressions
  2. What you use changes yourself, your way of thinking, and what you believe to be possible

The microwave oven was a huge advance in heating speed, but you lost the key aspect of temperature control. It is still difficult to find one that allows you to heat food to a particular temperature. Instead, you have to guess at the combination of watts and time. Software is even more plastic. You can be using code written by a 20-year-old Javascript newbie for reviewing the intricacies of your personal genome. Calling this entire technology a step forward or back is much too simplistic, and it lets said programmer off the hook for not knowing their own history.

Computer history should be a mandatory part of the curriculum. I don’t mean dry facts like the date the transistor was invented or which CPU first implemented pipelining. I mean criticism of historical choices in software or system design, and an analysis of how they could have been done differently.

Here are some example topics to get you started:

  1. Compare the Mac OS X sandboxing architecture to the Rainbow Series. Which is more usable? Compare and contrast the feature sets of each. Create an alternate history where modern Unix systems had thrown out UIDs and built on a data-centric privilege model.
  2. In terms of installation and removal, how do users expect iOS and Android devices to treat mobile apps? How does this compare to Windows programs or Linux packages? What are the potential side effects (in terms of system or filesystem changes, network activity, etc.) of installing a program? Running it? Removing it?
  3. Some developers have advocated “curl | sh” as an acceptable installation method as a replacement for native packages. They argue that there is no loss of security compared to downloading and installing a native package from an uncertain origin. Compare the functionality and risks of “curl | sh” to both a common package system (e.g., Debian dpkg) and an innovative system (e.g., Solaris IPS), focusing on operations like installing a package for the first time, upgrading it, installing programs with conflicting dependencies, etc. What is truly being lost, if anything?

Good design and engineering involves knowing what has come before, so we can move forward with as little loss as possible. Engineers should learn more about what has come before to avoid repeating the mistakes of the past. The past wasn’t better than the present, but ignoring it makes us all worse off than we could have been.