PocketCHIP Browser Installer Script


#1

I wanted to build something that is simple to use for the purpose of installing a browser, adding it to the pocket-home screen, and install ssh (but disable it from running automatically).

Safest way

wget https://raw.githubusercontent.com/SteveMcGrath/chipbuild/master/pocket_builder.sh
bash pocket_builder.sh

Safer Way

wget https://bit.ly/buildpchip
bash buildpchip

Unsafe way

wget -O- https://bit.ly/buildpchip | bash

This will update the repositories, then install the requisite packages (currently the browser is dwb) and replace the help icon with the web browser icon. Further as it’s installing ssh, I added a couple of aliases to help there:

  • sshon - Turns the SSH Daemon on.
  • sshoff - Turns the SSH Daemon off.
  • getip - Returns the IPv4 and IPv6 addresses currently assigned to the PocketCHIP.
  • ll - ls -al
  • pgr - pf -ef | grep
  • sagi - sudo apt-get install
  • sagu - sudo apt-get update
  • sags - sudo apt-cache search

NOTE: SSH will be turned on at the end of this script in case there is an issue. If everything looks ok after exiting the shell, just open a new shell and type sshoff to turn it off.

I would recommend that you take a look at dwb’s manpage, however the basics are right here:

  • D-Pad - scrolling around the page
  • o - Open URL
  • H - Back a page
  • L - Forward a page
    NOTE Case Sensitivity here is important.

The code for everything is located in this GitHub repo

(updated) I have also posted a blog entry detailing how to manually run through all of these actions on my site, stevemcgrath.io.


Softs on CHIP: Install and use
Screen size thoughts and questions
#2

This is nice…THANKS! I wanted to do something similar, but haven’t had time. Although I have some other packages that I will be adding to the install script. I have flashed mine twice and I can see it getting pretty cumbersome to manually reinstall everything each time.


#3

if you have any suggestions for what should be added here, im open to hear them.


#4

Sorry for asking, I know nothing about this, if I command that line in terminal (once I get my PocketCHIP), all of that will happen automatically?


#5

yes it will. It will at one point ask for a password, for which the default is simply “chip” it will set everything else up for you.


#6

That’s excellent! :smiley:


#7

Things I have been adding after flashing.

KDB (allows you to run “showkey - a” to see keymaps for configuring controls/buttons in emulators like mednafen).
DNSUTILS (because dig and nslookup are important networking tools)
ELINKS (mouse/touch capable text browser)
MOC (simple, lightweight terminal based music player)
RAINBOWSTREAM (terminal based twitter feed; requires python-pip and other dependencies to install though)
WEECHAT/IRSSI (terminal based IRC apps for connecting to #chipsters)

My aliases:

alias ll='ls -al’
alias pgr='ps -ef | grep '
alias rbs='rainbowstream -iot’
alias sag='sudo apt-get install ’ <---- because who wants to type out that everytime you need to install an app
alias xmm=‘xmodmap ~/.Xmodmap’ <----sometimes the keyboard layout gets goofy(I’ve had issues with |, or fn+p) and this fixes it

That’s all i can think of for now, but I’m sure there is some stuff I’m forgetting.


#8

I really have to register a complaint: “wget | sh” should never be a preferred method of installing software on someones system. Its totally unsafe, and has much potential for misadventure. This is a really bad habit that should be discouraged.

It would be far better to build a .deb package that contains the script, and then add the .deb to an officially-/community- maintained repo. This leaves users far less prone to MITM attacks, especially if said repo has proper crypto. Of course, this means we have to have such a repo up and running, and I hope there is a way this can be achieved without taxing NTC’s resources in the near future…

(This isn’t the first place, nor will it probably be the last, that this wget|sh method has been used to place software on someones system … but it should always be discouraged. You may as well just give total strangers access to your system and let them do whatever they want with it…)


#9

I don’t disagree, however with the lack of a community maintained repo, your only recourse is the break the pipe and download, then run the script.


#10

This is why we need a community repo, stat! I know NTC are real busy, but I sure hope they don’t go off the rails on this issue: a community repo is seriously needed before things get too weird with the larger user base that is inevitably on its way.


#11

Updated with some alternative methods of install. The script itself is pulling files from the repo as well. Technically I could break that, make the user unpack it, etc.


#12

I am inclined to agree with you, and I certainly would never enter that command directly (write to file first, examine for malware/mistakes before running). But really, is it any different from putting a program of unknown quality/intention into a repo and apt-getting it? In fact, I could even argue that with wget | more, I might easily be able to find something I don’t like, whereas I’m not sure how to examine an apt-get package.


#13

Well now you can choose your own level of safety. :wink:


#14

(We could probably start a new thread on this subject, if necessary.)

@fordsfords: there is a big difference between this and a community repo in terms of secure accountability. In the case of a repo if someone uploads something malicious, we have a way of determining who created the malicious code, and can act accordingly. We don’t actually know for sure, 100%, that there isn’t malicious code buried deep in some .deb package, but at least with a repo approach we have a mechanism by which we can audit the package, remove it if necessary, and update it on a mass scale if need be in order to service the users.

But with the MITM problem of wget|sh style operations, we may never know if there was any malicious activity - because its obviously a hidden thirdparty doing the MITM’ing and utilizing this security hole in the way the user is accessing the script.

Either way, I’d really prefer to see a much smoother transition to user-friendly repo’s, with package management for the user being handled in a GUI, than to have these sorts of hacks propagating all through the user base - or not. Of course this is an Operations decision that NTC have final authority over, as the progenitors of the OS, and I only hope that someone at NTC is thinking about this issue in a way that solves the problems and doesn’t give them (NTC) a support dilemna to deal with. Of course, I’d also be volunteering for the role of repo manager, in that case. :slight_smile:


#15

So I think i’ll keep this pretty barebones for the purposes of this script. I don’t want to start bloating the install needlessly (python-pip for example would take 70M+ from the repos), however with the ability to turn ssh on and off now, and the fact that there is a separate aliases file (located in ~/.profile_scripts/aliases.sh) it should be a lot easier to remote in and do any heavy-lifting from there.

I added irssi, moc, and dnsutils to the install, as now the collective weight of the script is about 15M to install everything. I also added ll, pgr, and sag to the default aliases.


#16

Yeah, if anything we can start forking it for the other stuff. i.e. here is the base script and here are common apps that you may find useful(with instructions on how to add them to the script, etc).


#17

Keep in mind that MITM with wget is only possible under 2 circumstances

  1. The attacker has a “valid” root CA. If this is the case, no matter what you do its technically game over if you touch the network.
  2. you explicitly tell wget to ignore the certificate the server is handing it (e.g. --no-check-certificate).

wget will fire an error if it’s a self-signed certificate or an invalid certificate and will refuse to continue. I haven’t specifically tested this on the chip, but unless NTC compiled a version of wget that doesn’t alarm on this, it’s generally relatively safe.


#18

Thanks @Ibisum, those are good reasons. Given the moderate effort required to create a .deb package v.s. the almost-non-existant effort required for wget pipe, I can see that while .deb might not be safer in theory, in practice it almost certainly is. It’s kind of like locking your door – everybody knows that it is easy for a professional to pick it in no time flat. But leaving your door unlocked allows any idiot (read “script kiddie”) to just waltz in.

Is that necessarily true? A group of us non-NTC people created the wiki. We asked NTC if they would mind and they didn’t, but even if they did, we probably would have done it anyway.

Seems like the only thing we owe them and ourselves is to avoid two repos at perpetual war with each other. So if NTC is nearing completion, then we should be patient. But if it’s on their “list of important things to do that we haven’t started yet,” then maybe we (read: you, with me helping where I can) should just do it.

Edit: and you’re right - I should have started a new topic. Sorry @stevemcgrath for hijacking your topic!


#19

Yup. Also the script does shim into .bashrc sourcing in any shell scripts in ~/.profile_scripts. Meaning that there isn’t a need to have expansive sprawl within a single file anymore. Things can be neatly laid out in different self-contained scripts.


#20

@stevemcgrath, true, but not every “pipe this .sh into exec”-type instruction starts with wget, etc. Arbitrary Code Execution is one thing, centralized repo of confirmed software packages that have maintainers keeping an eye on them, is another thing entirely.

Plus, there are no guarantees that, for example, someone nefarious doesn’t use an xss attack on this site to change that URL. I have no real trust in whatever bit.ly is …