Big Sky :: sudo の特権昇格バグはなぜ起こったのか
« Microsoft Word を Markdown に変換するコマンド「docx2md」を作った。 | Main | VimConf 2019 を終えて » Linux の sudo に root 権限を奪取できるバグが見つかった。 Linuxの「sudo」コマンドにroot権限奪取の脆弱性。ユーザーID処理のバグで制限無効化 - Engadget 日本版 この脆弱性は、sudoコマンドのユーザーIDに-1もしくは4294967295を指定すると、誤って0(ゼロ)と認識して処理してしまうというもの。0(ゼロ)はrootのユーザーIDであるため、攻撃者は完全なrootとしてコマンドを実行できることになります。 https://japanese.engadget.com/2019/10/14/linux-sudo-root-id/ 既に Ubuntu 等にはパッチが配布され始めているらしい
"Android Studio最速入門" 第32回に関する指摘 - 彷徨えるフジワラ
連載 "Android Studio最速入門〜効率的にコーディングするための使い方" における "第32回 バージョン管理─Mercurial連携の使い方" での Mercurial 連携に関する説明で、気になる点があったので、まとめておこうと思います（筆者の方には報告済み）。 ある程度 Mercurial を使い込んでいる人であれば、多分言うまでもない話かもしれませんが、Git と併用しているような人や、Mercurial 初学者の誤解を防ぐことができれば幸いです。 あちらの記事の読者が、こちらのエントリに辿りつけるのかは、微妙なところではありますが、まぁ、そこはネット（＋検索）の力を信じることにしましょう（笑）。 リポジトリを最新の状態に保つ 1ページ目の「リポジトリを最新の状態に保つ」での: つまり，hg pullはGitでいうgit fetch相当なので，git pullに相当する
パッチ管理リポジトリ入門 ～MQ(パッチ)もMercurialで管理できるよ～ - secretbase.log
先日 pyfes でご挨拶させていただいた @IanMLewis さんからバトンを受けまして Mercurial Advent Calendar 2012 - connpass 本日4日目の記事を書かせて頂きます。 パッチ管理リポジトリ入門ということで、MQ自体の管理について簡単にご紹介させていただきたいと思います。 パッチ？ そもそもパッチとはなんでしょうか？ここでいうパッチとはMQのことです。え？よくわかりません。そうですね。 簡単にいうと、 diff の固まり です。Mercurialのチェンジセットのひとつひとつは結局は差分に過ぎません。 よって、コミット済みのチェンジセットもdiffの固まり（つまりMQ)に変換することができます。 この MQ を自在に使いこなすことで、Mercurialの持っているパフォーマンスを最大限引き出すことができます。 MQの詳細については、TokyoM
Mercurial Advent Calendar 2012 (2012/12/01 00:00〜)
12月 1 Mercurial Advent Calendar 2012 みんなでtipsを積み重ねましょう！
obsolete 機能 - 彷徨えるフジワラ
来月(８月)冒頭にリリースされる Mercurial 2.3 版から、 obsolete (marker) と呼ばれる機能が追加される。 >>>> 2012-08-04 追記： ここから 2.3 リリース直前に、デフォルトでは obsolete 設定の追加を抑止する修正が入った模様。 そのため、2.3.x 版で試験的に obsolete 機能を試してみようと思う場合、以下のようなエクステンションを使って obsolete 機能を有効にしてやる必要がある (後述する evolve エクステンションを有効にする方法も)。 from mercurial import obsolete def uisetup(ui): obsolete._enabled = True なお、リリース間際のバタバタの影響なのか、59c14bf5a48c と a1f8869f2eee の２つのリビジョンで "_ena
(特に Git 併用ユーザには是非読んでおいて欲しい) Mercurial における『ブランチ』の概念 〜 その１ - 彷徨えるフジワラ
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
Mercurial でのサブリポジトリの利用 - 彷徨えるフジワラ
ここ暫く、#TokyoMercurial (+ 懇親会)の席や twitter上などで、サブリポジトリ(subrepo)の利用に関する質問等が多かったのですが、口頭説明や、twitter の文字制限内では、なかなか正確に伝えるのが難しかったので、ブログエントリとしてまとめてみました。 っつーか、ある程度書きあがってから、僕の勘違いに突っ込みが入って、慌てて加筆修正しました(笑)。指摘感謝です！ > @yujauja 氏 サブリポジトリの利用開始 Mercurial のサブリポジトリ機能とは: Mercurial リポジトリを親に、外部のリポジトリやプロジェクトを入れ子にし、 コマンドの実行の際に、 それら一連のリポジトリに対して処理を行えるようにします。 〜 "hg help subrepos" より というものです。 サブリポジトリの追加手順は、hg help subrepos (日本語
Git 対 Mercurial：なぜ Git を選ぶのか？ - Atlassian Japan
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
Mercurial 対 Git：なぜ Mercurial を選ぶのか？ - Atlassian Japan
ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。 履歴が安全な Mercurial Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。 G
rebaseのイメージ - プログラマの思索
@yusuke_kokuboさんのつぶやきでrebaseのイメージがようやく分かったのでメモ。 【元ネタ】 Twitter / @akipii: とても分かりやすい RT @yusuke_kokubo: ブランチのmergeは2つのブランチが合流するのに対して、 rebaseは一方のブランチがもう一方のブランチに(分岐元から派生した分を)吸収するようなイメージをしてる Rebaseとトピックブランチ: プログラマの思索 mergeは衝突がなければ、派生ブランチをtrunkへ取り込んでくれるが、衝突があれば、マージしてくれない。 rebaseは、trunkへ派生ブランチで育てたパッチを合流するように取り込んでくれる。 つまり、rebaseはtrunkの履歴を壊さず、その履歴の上に派生ブランチの履歴を取り込んでくれる。 「入門Git」にもrebaseについて詳しく解説されている。 trunkに
mercuiralを使いながらgithubのpull requestを取り込む方法 - 放牧日記
http://partake.in/events/95ab571f-c477-43dd-8d96-396d3b670b6f:title=の成果発表です。 先日あるmercurialリポジトリのミラーリポジトリをgithubに作成したところ、開発がgithubに移ってしまうという(mercurial使い的には)ショッキングな出来事がありました。mercurial使いはいろいろ肩身が狭いですね。 それもこれも、「mercuiralを使いながらgithubのpull requestを取り込む方法」についてのノウハウが共有されていないことに問題があります。今後、二度と悲劇を繰り返さないために考察してみました。 想定する構成 考察した結果です。 bitbucket-and-github urlは次の通り central repository https://bitbucket.org/troter/
あるプロジェクトのMercurial導入の軌跡 - 放牧日記
このエントリはMercurial Advent Calendar 2011 - PARTAKEの25日目です。 3月からMercurialを使い始めたので12月で9ヶ月目になります。一年の振り返りという事で、Mercurial導入の軌跡について簡単にまとめたいと思います。*1 Mercurialとの出会い Mercurialと出会う前はSubversionとちょっとだけGitを触っていました。とくにSubversionは仕事でかなりがっつりブランチの運用*2を行っていました。 嫌になるほどSubversionを使うプロジェクトでは次の問題が発生していました。 Subversionでのブランチマネジメントはマージ担当者の負荷が高すぎる リポジトリが巨大になりすぎてsvn stするだけでも20秒 リポジトリが巨大になりすぎてsvn upが終わらない 部分svn upし出す人が増え、整合性に関す
SCMBootCamp in Tokyo 2 を振り返って - 彷徨えるフジワラ
※ 2011/11/27 追記あり 時間枠中は、Twitter のタイムラインを見ている暇が無かったので、togetter でのまとめを元に、落穂拾い的に tweet された質問／疑問に答えることに。 まとめて頂いた @shinyaa31( id:absj31 ) 氏に感謝！(※ @shinyaa31氏自身のまとめはこちら) そして、改めて主催の id:kyon_mm 氏に感謝！ 基調講演枠での tweet 講演内容は好評だったようで一安心。 SCM ツール世代分類に関して: (@oota_ken) ClearCaseはClearCaseはClearCaseは まぁ多分、「ClearCase も忘れないであげてください」ニュアンスだとは思うけど、一応答えておく事に(笑)。 私自身、ClearCase を触ったことが無いので、『パターンによるソフトウェア構成管理』に記載された情報ベースで見る
Mercurial 入門セッション資料 - SCM Boot Camp #2 — SCMBC 2011.11 Mercurial Intro-Session 0.0.1 documentation
この資料について¶ SCMBC #2 Mercurial 入門セッション資料です。 http://bitbucket.org/troter/scmbc-2011.11-mercurial-introsession この資料ではMercurialを利用するに当たって必須の用語や概念について説明しています。 この後の演習で参考になるよう、効果的に利用する為のお作法、作業フローについても解説します。 (狭義の)リポジトリ¶ SCM ツールにおいて、 作成／改変／移動／削除といったファイルに対する作業内容や、 実施者／日付といった 「履歴」 (history) に関する管理情報を格納しておく領域を、 (狭義の)「リポジトリ」 (repository) と呼びます。 作業領域¶ リポジトリに格納されている情報を元に、 ファイルを取り出したり、 取り出したファイルに対する作成／改変／移動／削除といった
Mercurialでのブランチ
Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. まぁ、自分がMercurialユーザーだったらvim-jpの記事を読んで間違いに気づくはずだ。 まず、Mercurialでのブランチというのはどういうものが理解すべき。Mercurialでは、ブランチというのは、一種のtagとheadsの総称でしかない。gitだとローカルブランチとリモートブランチという概念があって、ブランチをpushするときには、特別な方法を取る必要があるけど、mercurialの場合は通常のpushに自分で作ったブランチが含まれてしまう (もちろんheadsが合わなければリジェクトされるし、明示的にブランチへのpushを使う必要もある)。 だから、多数での開発をしてる際に自分のコードを管理するためにブランチを作るのはよくない。Mer
Mercurialでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
前回[@kana1さん](http://twitter.com/kana1)による[「gitでアレをもとに戻す108の方法」](/tech/git-undo-999)が大反響で世間はやはりgit使いが多いのかと再認識しました。 私も普段はgitを使っていますが、お仕事ではMercurialを仕事で使っているのでのっかって書き連ねてみましょう。 ### 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いていくつかコミットした。でももういらない さて初っぱなから行き詰まりそうです。基本的にMercurialは「コミットを積み重ねたものを後から編集する」ことに弱いのです。 MQを使って解決してみましょう。 $ hg update -r {revision} $ hg qimport -r {revision+1}:tip $ hg qpop –all $ hg qseries |
はじめてのMercurial/Bitbucket :: handsOut.jp
スライド1: はじめてのMercurial/BitbucketCodeIgniter and its logo are property of EllisLab Inc日本CodeIgniterユーザ会Kenji Suzuki2011/02/19CodeIgniter Users Group in Japan スライド2: 目次・ Part 1 バージョン管理システムとは?・ Part 2 Mercurialとは?・ Part 3 Mercurialの使い方(1) ~ 基本的な使い方 ~・ Part 4 Mercurialの使い方(2) ~ 複数リポジトリの使い方 ~・ Part 5 Bitbucketとは?CodeIgniter and its logo are property of EllisLab IncCodeIgniter Users Group in Japan スラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pythonista も �ls を読むべきか？
Charming Python: Functional programming in Python, Part 3
分散リポジトリ型時代のソフトウェア構成管理