home

หน้าแรก
 Computer >> บทช่วยสอนคอมพิวเตอร์ >  >> การเขียนโปรแกรม >> Ruby

ทำไม Self-Hosting Ruby Gems ถึงปลอดภัยกว่า RubyGems.org ใน Production

บทความราว + screencast แสดงวิธี host gems เอง

มาทำความเข้าใจกันก่อน: gems เป็นสิ่งยอดเยี่ยม และ RubyGems.org เป็น service ที่ดี

...แต่近期 ผมรู้สึก queasy ทุกครั้งที่เพิ่ม gem ใหม่ใน app ยิ่งคิดยิ่งรู้สึกว่าวิธีที่เราใช้ gems ไม่ได้แค่ flawed มันคือ disaster waiting to happen

Social engineering FTW

ไม่กี่วันก่อนที่ RubyNation Ben Smith ให้ talk ยอดเยี่ยมชื่อ Hacking With Gems

ไม่ใช่ hacking on gems แต่ใช้ gems เป็น way to hack...เป็น attack vector

เขาทำ experiment เยี่ยม

ถ้าคุณอยู่ conference น่าจะเห็น stacks ของ printed cards ใกล้ github stickers และ swag อื่นๆ

Card บอกอย่างเดียว: gem install rubynation และประมาณ 10% ของ attendees ทำ

ทำไม Self-Hosting Ruby Gems ถึงปลอดภัยกว่า RubyGems.org ใน Production

สิ่งที่ gem ไม่ได้ทำ

Gem ทำ useful things บางอย่าง แต่สิ่งที่ไม่ได้ทำน่าสนใจกว่า

มันไม่ได้:

  • ขโมย RubyGems.org credentials จาก gemcutter dotfile ของคุณ

  • Intercept plaintext passwords เก็บใน rails /public directory ของคุณ

  • เพิ่ม secret SSH account เข้า system ของคุณ

แต่มันทำได้ ถ้าไม่เชื่อ ถาม Ben

สิ่งนี้ควรทำให้คุณกลัว

ให้ผมพูดอีกครั้งให้จดจำ

ประมาณ 25 คน - COMPUTER PROGRAMMERS - ถูก manipulate ให้รัน arbitrary code บน development machines ของพวกเขา บางคนแม้แต่รัน as root

ผมไม่ได้หมายจะจับผิดคนเหล่านี้ นี่คือ norm ใน Ruby community

ทำไมถึงเกิดขึ้น?

People trust gems

  • เพราะมันมักทำงาน

  • เพราะ Rails เป็น gem

  • เพราะ well-known folks เช่น Aaron Patterson, Steve Klabnik, Yehuda Katz maintain พวกมัน

แต่มันเป็นปัญหาเมื่อเริ่ม trust คนที่ไม่รู้จัก

เป็นปัญหาเมื่อคุณพิมพ์ gem install rubynation โดยไม่ลังเลมากกว่า gem install rails

และมาพร้อมกับความจริง ใครไม่เคยทำอย่างน้อย 1 ครั้ง? เราขี้เกียจและ gems ง่าย

RubyGems.org ไม่ต้องรับผิดชอบ

มันแค่ทำให้ทำผิดได้ extremely easy รัน untrusted code บน servers ของคุณ ไม่ informed เกี่ยว changes ในโค้ดที่รันบน servers ของคุณ

นั่นคือเหตุผลที่ผม suggest เราทั้งหมดหยุดใช้มันใน production

Solutions

Signatures ไม่พอ

ทุกคนควร sign gems ของพวกเขา แต่ signatures ไม่พอ Signature แค่ verify identity ของ publisher ไม่บอกว่าพวกเขา good, evil หรือ chaotic neutral

ไม่มีใครมาช่วย

ใน perfect world เราจะมี trusted organization ที่ distribute versions ของ gems ที่รู้ว่า good

ถ้ารู้สึกไม่ถูกต้อง คิดถึง organizations เช่น Debian ทำอย่างนี้สำหรับ Linux ถ้ายังรู้สึกไม่ถูกต้อง... well ผมหumbled ว่าคุณอ่าน blog ของผม Mr. Stallman

ทำไมพูด perfect world? เพราะ alternatives อื่นๆ มากงาน ผมชอบไม่ทำ

...ใคร YC hopefuls อยากได้จัดการนี้ไหม?

The only real option: DIY

น่าเสียดาย ผมต้องอยู่ใน smelly old real world นี้ วิธีเดียวที่แท้จริงให้ total control over gems คือ

  • Review code สำหรับ treachery

  • Host gems เอง

โชคดีที่ host gems เองง่าย ผมจะแสดงวิธี

วิธี host gems เอง

ทำไม Self-Hosting Ruby Gems ถึงปลอดภัยกว่า RubyGems.org ใน Production

It's not magic

Gem "server" แค่ bunch of flat files บน web โฮสต์ได้ที่ไหนก็ได้ แม้ S3 หรือ dropbox

สร้าง Rails app เป็น testbench

เหตุผลเดียวที่ใช้ rails ที่นี่คือมันให้ premade Gemfile เล่น app นี้ไม่ทำอะไร

`$ rails new myapp
$ cd myapp `

Download .gem files

Bundler command นี้ download .gem files ทั้งหมด referenced by Gemfile.lock ใส่ /vendor/cache

`$ bundle package
$ mkdir /tmp/gem_server
$ mv vendor/cache/ /tmp/gem_server/gems `

Generate 'server' files

เพื่อนำ directory ของ .gem files ทำให้ ready for serving รัน gem generate_index

`$ gem generate_index -d /tmp/gem_server/ `

Put it all online

ตอนนี้ผมไม่แนะนำใน production แต่...

`$ mv /tmp/gem_server /Users/snhorne/Dropbox/Public/ `

Edit Gemfile และ bundle update

Update "source" line point ไป host ใหม่แทน rubygems

`# Gemfile
source 'https://dl.dropboxusercontent.com/u/12345/gem_server'
...
gem 'rails', '3.2.13' `

Cool! มัน pull gems จาก dropbox ของผม

`$ bundle update
Fetching gem metadata from https://dl.dropboxusercontent.com/u/12345/gem_server/.
Fetching full source index from https://dl.dropboxusercontent.com/u/12345/gem_server/
Using rake (10.1.0)
Using i18n (0.6.1)
Using multi_json (1.7.7)
Using activesupport (3.2.13) `

Bonus: Private gems ป้องกันด้วย HTTP basic authentication

แค่ทำ Gemfile แบบนี้:

`# Gemfile
source 'https://username:password@example.com/' `

Alternatives

ถ้า approach นี้ไม่ work สำหรับคุณ มี free และ commercial gem hosting solutions ให้ bells and whistles เพิ่ม

Geminabox เป็น open source application eliminate command line work มาก

Gemfury เป็น private gem hosting company ผมเคยใช้ host proprietary gems ให้ client ตั้งค่าง่ายและไม่มีปัญบูม