ときどきの雑記帖″

最新ページへのリンク
目次ページへのリンク

一つ前へ 2014年9月(下旬)
一つ後へ 2014年10月(中旬)

ホームへ

2014年10月09日

■_

2014年版が!(現在第3回まで) 情報技術者の社会的責任 2014 第1回

■_

■_

gpc、やっぱり開発止まってたのね。

Quo vadis, GPC?

Quo vadis, GPC?

Frank Heckenbach ih8mj at fjf.gnu.de

Tue Jul 27 00:16:43 CEST 2010

Hi everybody,

since GPC development has mostly stalled, I've thought about if and
how its development could be continued. Here are my current thoughts
about it. Since the text is quite long, I put it on the web:
http://fjf.gnu.de/gpc-future.html

As I write there, I don't see much future in the current way of
developing GPC, but also alternative development models will not be
a task for a single person. In other words, without some new
contributors, there is probably no chance for GPC development to
continue.

以下略

メール中にリンクのあったこれにもいろいろと

Quo vadis, GPC?

Quo vadis, GPC?

As you have surely noticed, GPC development has stalled recently and questions about GPC's future have been
raised. I've thought about the issues for a while, and here are my thoughts.

I started as GPC's main developer and maintainer some 10 years ago, following Peter Gerwinski and followed by
Waldek Hebisch, though with some overlap each time. Recently, GPC development has almost come to a standstill
as all three of us have focused on other projects, and have not had the time nor the necessity to do significant
GPC development.

Back then, Peter Gerwinski, and occasionally I, professionally worked on some larger Pascal projects. These
projects are now finished (as far as we are concerned), so for our professional work, there is currently no
more interest in GPC. In recent years, Peter and I have done our professional work in other languages, mainly C++.

以下略

■_

良くまとまってるんで訳したらいいんじゃないすかね Shellshock

Shellshock
Shellshock
David A. Wheeler
2014-10-08

This paper covers the basics of the shellshock bash vulnerability, a discussion on ways to detect or prevent
future Shellshock-like vulnerabilities, a timeline of what happened when, and some information about the specific
CVEs (vulnerability identifiers). It ends with a few conclusions.

Shellshock basics

The shellshock vulnerability is a vulnerability in the widely-used bash command shell. This vulnerability had a
huge impact. Here I will discuss the initial disclosure, the realization that there was a bigger problem, how
to detect the shellshock vulnerability, naming shellshock, and the general aftermath.

Timeline

Below is a timeline of shellshock, including citations to justify it. There were many unintentionally-incorrect
reports of times, so the data below differs from many earlier (incorrect) reports. My sincere thanks to those who
helped, including Stéphane Chazelas (e.g., for vulnerability insertion dates and report times) and Eric Blake
(e.g., for bash patch dates). Remember that people do not necessarily represent the organizations they work for.
  

1989-08-05 08:32:05 -0700 (timezone estimated)	Shellshock vulnerability accidentally introduced into the development version of bash by then-lead bash developer Brian Fox, as part of an addition to support function export and import. The date of insertion is confirmed by a bash ChangeLog. The “code is very simple, it just replaces the = with a space in the environment entry and interprets it”. Chet Ramey notes on 1989-09-02 that an advantage of bash over ksh is that bash supports function export. A later post by Brian Fox on 1989-09-08 04:54:05 EDT also notes that bash 1.03 can export functions, and explains how: “Upon reading in the environment, if a string of the form “name=() {“ is found, then that is a function definition.” This is the mechanism that turns out to be vulnerable. More information is posted at StackExchange responses to “When was the shellshock (CVE-2014-6271/7169) bug introduced, and what is the patch that fully fixes it?” The timezone is estimated from the fact that Brian Fox moved to Santa Barbara in 1987 and daylight savings time would have been in effect (thanks to David Woodhouse for reminding me of the latter correction). Note that this date is relatively soon after the first beta release of bash (1989-06-07), and bash development had only begun in late 1987. My thanks to Eric Kobrin (Akamai) who found this information and also to Stéphane Chazelas who posted the information to oss-security on 2014-10-04 09:19:07 +0100 (alternate link). This date (and supporting information) was difficult to track down, so many early reports gave the wrong date for vulnerability insertion (1992 is incorrect).
1989-09-01 18:52:08 -0700 (timezone estimated)	Brian Fox releases version 1.03 of bash with the vulnerability included in it. The sources for this information are the same as the previous entry; here is a brief discussion about this date.
2014-09-12 16:10:35 +0100	Stéphane Chazelas reports the vulnerability in bash to Chet Ramey (the lead bash developer) and the security contacts of Debian, Red Hat, Ubuntu and Mandriva (SUSE was added later). This included “details of the bug and the SSH and HTTP (Apache header) vectors and mitigation and a bit fat warning that it was very serious and not to be disclosed”. This newly-found vulnerability was assigned the identifier CVE-2014-6271. Stéphane Chazelas found this vulnerability in the morning of the same day (2014-09-12 in the UK), after reflecting on an earlier vulnerability he had reported in libc (CVE-2014-0475) that had involved environment variables and was aggrevated by design choices in bash. As is routinely done, release of details was briefly embargoed. Private discussions were held about the best way to solve the problem, and patches were developed by the bash developer Chet Ramey for a planned coordinated announcement. There were conflicting reports about the date; the dates and other information reported by Stéphane Chazelas himself are used here (because he is a primary source). The article “Stéphane Chazelas: the man who found the web’s ‘most dangerous’ internet security bug” by Ben Grubb, The Sydney Morning Herald, September 27, 2014, provides some interesting early information, but it includes an incorrect date of 2014-09-09 as the report date, and it also incorrectly claims that the previous vulnerability Chazelas reported was in bash (it was actually in GNU libc, and merely aggrevated by bash functionality). The article “Security Experts Expect ‘Shellshock’ Software Bug in Bash to Be Significant” by Nicole Perlrothsept, The New York Times, 2014-09-25 gives the correct Shellshock report date, 2014-09-12.
2014-09-14 14:29:48 +0100	Stéphane Chazelas proposes that this vulnerability be named “bashdoor”. However, this proposed name is not mentioned in early announcements of the vulnerability, and in the end this name does not catch on.
2014-09-16 22:00:02 -0400	Chet Ramey has all final (before disclosure) fixes for the current and all past versions of bash back to 3.0 by 2014-09-16. Source: Stéphane Chazelas.
  

(C) Copyright 2014 David A. Wheeler. 

なんと1989年から潜んでいたとは

2014年10月08日

■_

「俺はお前のかませ犬じゃない」 は10/8の出来事だったとか。 長州力名言1 長州力「藤波さんの“噛ませ犬”発言? アレはマスコミが書いたものです」 - エキサイトニュース(1/2) 長州力 - Wikipedia

月食は中途半端に見た。 皆既の辺りでは思いっきり雲に隠れてたし

■_

2014年10月07日

■_

昨日の社食のメニューに自分の好きなのがあったのを知ってちょっと悔しい

■_

■_

終わったのか Why The C/C++ Computer Programmer Career Is Over? : Software Developers Training

We don’t recommend C/C++ computer programmer careers for the following reasons: として挙げられた項目はこう。

2014年10月06日

■_

自主的に休み。

■_

■_ cp/m

Early Digital Research CP/M Source Code | Computer History Museum

新・電子立国でのキルドールのインタビューもう一回見たいなあ

んで

Early Digital Research CP/M Source Code | Computer History Museum

The source code

We are releasing scanned printer listings and/or machine-readable source code for four early versions of CP/M
dating from 1975 to 1979.  Some versions are incomplete, but please don't ask us for what is missing because we
are releasing everything we have.

This material is provided for non-commercial use only. All the files are combined into one ZIP file with four
directories representing the four versions.

アーカイブがずいぶん大きいと思ったら複数のバージョンが入っているらしい。 それにしても大きいとは思うけど(まだダウンロードしていない)。

Early Digital Research CP/M Source Code | Computer History Museum

Do you like this?

If you would like to support the Computer History Museum's efforts to preserve and publish historic source
code like this, please consider making a voluntary contribution. 

多少なりとも寄付しておきますかね。

2014年10月05日

■_

某社の対応 (略)出勤時には気象・交通情報を確認の上、安全に留意して出社してください。

というわけで、10月からの放送大学の番組では数理論理学 (4月からので観てたけどタブローの辺りで脱落しちゃったのねん) と線型代数をチェック。

お、スマリヤン先生の本だ。

■_

■_

積ん読を中途半端に消化した一日。

2014年10月04日

■_

なかなか面白かった。 jesusfv/Comparison-Programming-Languages-Economics Are We There Yet? Simple Language-Implementation Techniques for the 21st Century

■_

■_

出版が続くのは良いのだけど、赤字があってもそれを補填するところがあるからというのは 望ましい状況じゃあないよね。たぶん。

■_

…流行?

2014年10月03日

■_

今日の夕方から月曜朝の運行状況がどうのという案内が出ていた>東急 某社は例によって例のごとしなんだろうねえ。

■_

前から公開されてた(読めた)ような気がするんだけど、 あれは公式のものではなかったということなんだろうか。

■_

■_

2014年10月02日

■_

SRGM。論文を時折検索して見つけてるんだけど、 どうも同じ人たちがたくさん手を変え品を変えて書いてるような印象があるんだよなあ (具体的な名前は出さないけど)。 基本的なやり方(確率微分方程式を使って…とか)は大きく変わらないけれど、 年を追うごとに精度が上がっているのなら(論文の記載を信じるならね)、 10年、20年前とはかなり違った数字になりそうなもんだけど そういう印象ないよねえ。

■_

■_ new programming jargon

はてなブックマーク - 【翻訳】あなたは全部知っていますか?プログラミングの業界用語30選 | POSTD 【翻訳】あなたは全部知っていますか?プログラミングの業界用語30選 | POSTD 7. Stringly Typed (謎の型付け) なんでこれが「謎の型付け」になるのかよくわからん。 それからこの元記事は二年くらい前にも話題になってるんで このタイミングで訳した理由が今ひとつわかんない。 知らなかった(見つけられなかった)? 新しいプログラミングのジャーゴン - YAMDAS現更新履歴 Island Life - New programming jargon Stack Overflow発 プログラミングの隠語(ジャーゴン)30選 | A-Listers Stack Overflow発プログラミングの隠語(ジャーゴン)30選:海外テック情報局|gihyo.jp … 技術評論社

【翻訳】あなたは全部知っていますか?プログラミングの業界用語30選 | POSTD

strong typied(強い型付け)をもじったもの。プログラマやリファクタリングがうまく使える状態なのに、不必要に文字列を使った実装のことを表わします。

例:

    より適切な型があるのに、文字列を使うメソッドのパラメータ
    文字列がメソッドの呼び出しで必要とされる場合。(ネットワークサービスなど)文字列が渡されて、最初により適切な型に変換せずに、残りのコールグラフを通して使われる。(解析してenum型を生成し、残りのコードベースを通して強い型付けを行うなど)
    型付けされたメッセージを使わずにパスするメッセージなど
New Programming Jargon

7. Stringly Typed

A riff on strongly typed. Used to describe an implementation that needlessly relies on strings when programmer & refactor friendly options are available.

For example:

    Method parameters that take strings when other more appropriate types should be used.
    On the occasion that a string is required in a method call (e.g. network service), the string is then passed and used throughout the rest of the call graph without first converting it to a more suitable internal representation (e.g. parse it and create an enum, then you have strong typing throughout the rest of your codebase).
    Message passing without using typed messages etc. 

Excessively stringly typed code is usually a pain to understand and detonates at runtime with errors that the compiler would normally find. 

これはさらにもうちょっと前(2011年11月) Dodgy Coder: "Yoda Conditions", "Pokémon Exception Handling" and other programming classics

2014年10月01日

■_

C for Rubyists | Hacker News C for Rubyists : programming で話題になっているサイトの使い道が良くわからんげ。

■_

■_

この本の。

熱血!アセンブラ入門

557ページ 18.02.06 「インクリメント演算子」の元になった命令がある のところに

さて PDP-11といえば冒頭でも紹介した、ちょっと有名な話があります。

C言語には「++」という演算子があり、変数のインクリメント(1を加算すること)に利用されます。 例えば「i = i + 1」のような演算はC言語では「i++」と書くのがふつうです。

これはUNIXのコーディングのためにC言語がPDP-11向けに開発された当初、 PDP-11がインクリメント命令を持っていたため、 それを利用するための演算子として追加されたという話です。

と書かれているのですが、 dmr その人による C の開発史によれば

Chistory

More History

After the TMG version of B was working, Thompson rewrote B in itself (a bootstrapping step). During development,
he continually struggled against memory limitations: each language addition inflated the compiler so it could
barely fit, but each rewrite taking advantage of the feature reduced its size. For example, B introduced
generalized assignment operators, using x=+y to add y to x. The notation came from Algol 68 [Wijngaarden 75] via
McIlroy, who had incorporated it into his version of TMG. (In B and early C, the operator was spelled =+ instead
of += ; this mistake, repaired in 1976, was induced by a seductively easy way of handling the first form in B's
lexical analyzer.)

Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or
postfix position determines whether the alteration occurs before or after noting the value of the operand. They
were not in the earliest versions of B, but appeared along the way. People often guess that they were created to
use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first
became popular. This is historically impossible, since there was no PDP-11 when B was developed. The PDP-7,
however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference
through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization
to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in
implementation of the operators, and a stronger motivation for the innovation was probably his observation that
the translation of ++x was smaller than that of x=x+1. 

ちゃんちゃん。


一つ前へ 2014年9月(下旬)
一つ後へ 2014年10月(中旬)

ホームへ


リンクはご自由にどうぞ

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp