djangoproject.jp

TokyoDjangoMeetup#9を開催しています

2016-12-03T05:23:37+00:00

今日 TokyoDjangoMeetup#9を開催しています。

皆さんの自己紹介とやること。

nakaishi: DjangoでBPで仕事をして。BitbucketにあげてるDjangoチュートリアルを最新に追随する。ドキュメント内でタブ切り替えでDjangoのバージョンを変えて見れるようにしたい。Djangoの相談とかあればして欲しい
fujimoto: https://twitter.com/fujimisakari Djangoで仕事で開発している。仕事でコードレビューを良くしている。Pythonのレビューとかもできるので相談して欲しい。ReactのAdventカレンダーを書かないといけない。Pythonのアドベントカレンダーも書かないといけない。PyPIに登録したactionlogというものについて書きたい
salexkidd: Python、Djangoをやっています。今日は仕事をする
akihironemoto: 転向してエンジニアになるのでPython、Djangoの勉強する。スクールでPythonのメンターとかもやっている。
aoino: DjangoどころかPythonも初心者なのでチュートリアルから頑張る
t02uk: 社内でアプリを作ってるから他の人も見てみたい。スクラップから何かを作ってみたい。
matsunaga: スタートアップだけどDjangoやってる人が周りにいない。Djangoのアドベントカレンダーも建てた。ちゃんとsettings.pyの使い方とかを見直してプロダクトを考え直したい
yamada: 学生さん。初心者で、チュートリアルをやっていく
soutarou: アルバイトでDjangoを使ってる。英語を勉強するアプリのバックエンド。Reactがフロント。1週間で作ったプロダクトの
inagakisan: 社会人2年目でSE。Pythonに興味あった。つまっちゃったところを聴きたい。
jack: Djangoの勉強にきた。フリーランスでやってる。C系をやっている。機械学習とか接点あったら知りたい
Massa: 転職TipsアドベントカレンダーとDjangoアドベントカレンダーを書く

DjangoGirlsTokyoが開催されます

2015-06-24T01:50:36+00:00

7月26日にDjangoGirlsTokyoが開催されます http://djangogirls.org/tokyo/

参加登録は connpassのページからどうぞ。

DjangoGirlsって?

これからWebサイトの作り方を学びたい、プログラミングを学びたいと思っている女性のみなさん、初心者向けの1-Dayワークショップが開催されます。DjangoGirlsは国際的なイベントで、世界各国でも地域別DjangoGirlsが開催されています。

DjangoGirlsをサポートしたい!

Djangoに詳しい方はぜひコーチの応募を。応募は tokyo@djangogirls.org に連絡すればOKだそうです。

企業の方は connpass のページからスポンサーに応募してみてはいかがでしょうか。

Django1.8ドキュメント翻訳についてのアンケート結果

2015-05-30T02:39:50+00:00

以前お願いした Django1.8ドキュメント翻訳のアンケートの結果を報告します。

アンケートの結果

以下が結果のサマリです。

18人の人がアンケートに回答
「Django1．8ドキュメントの日本語翻訳は必要」=>16人
「翻訳がある嬉しい項目」=>「モデル」が1番多く、次が「チュートリアル」
「翻訳に足りない情報」=>「参加方法がわからない」「誰が翻訳しているかわからない」が同率で1番多い
「翻訳の欲しい程度」=>「イントロ・チュートリアル」「トピック」「リファレンス」がほぼ同率

結果のすべては Django1．8ドキュメント翻訳アンケートから見れます。

結果をもとに djangoproject.jp の改善を行っていきます。翻訳への参加方法に情報を追加します。

Django1．8ドキュメント翻訳についてのアンケート

2015-04-29T05:02:51+00:00

Django1.8ドキュメント翻訳に際してのアンケートです。

日本語での情報が必要とされているページはどれか、djangoproject.jp上に足りてない情報は何なのかの調査です。結果は djangoproject.jp 上で公開します。翻訳する人のモチベーションになればと思っています。

次回TokyoDjangoMeetupの予定日 5月30日まで、受け付けます。アンケートは以下のGoogleFormから投稿してください。

http://goo.gl/forms/sfCDzAFmnb

Django1.8リリースのお知らせ

2015-04-01T23:44:50+00:00

Django1.8がスケジュールどおりリリースされました

このバージョンは long-term support (LTS) のリリースです。セキュリティ、データロスの修正が少なくとも向こう3年行われます。

リリースノートに内容は書かれていますが、メジャーな変更のハイライトはこちら

複数テンプレートエンジンmultiple template enginesのネイティブでのサポート
ORMからの複雑なSQLのサポート
Model._metaへの正式なAPIのサポート
contrib.postgresでのPostgreSQL用機能の提供

ダウンロードページかthe Python Package IndexからDjango1.8をダウンロードしてください。このリリースのPGP key IDは Tim Graham: 1E8ABDC773EDE252 です。

Django1.8のリリースにより、Django1.6シリーズのサポートは終了します。 1.6.11 が最後のリリースになります。Django 1.7のセキュリティアップデートはDjango1.9のリリースまで続けられます。(2015年10月予定)。 Django 1.4 (前回の LTS) は向こう6ヶ月間(2015年10月1日まで)セキュリティアップデートが行われます。ユーザーは Django 1.8 LTS に移行してください。

Django 1.7.1 リリース

2014-10-24T09:46:07+00:00

Django 1.7.1 がリリースされました。バグフィックスリリースとしてです。

Django1.4.16, 1.5.11, 1.6.8, 1.7.1がリリースされています。 Django 1.5 はすでにサポートの対象外ですが、今度こその最後としてバグフィックスがリリースされています。

Django 1.7 リリース

2014-09-03T09:44:43+00:00

1年あまりの開発期間の末、本日 Django1．7 が正式にリリースされました。

いつものようにリリースノートに 1.7 でカバーされている全てが詳細に書かれています。メジャーなもののハイライトは以下:

ビルドインのマイグレーションシステム。 South からのアップグレードも可能です
Django のアプリケーションシステムのリファクタリング。Django のアプリケーションが models ファイルに依存しなくなり、コンフィグと Django 起動時のコード実行を指定できます。
マイグレーションに対応するためにモデルフィールド (Field) の API を改善。将来的に複合キーを簡単に追加できるようにもする予定です。
カスタムマネージャーとクエリセットクラスの改善。逆方向へのリレーションの探索からManagerを使えるようになり、カスタムの QuerySet クラスから Manager クラスを生成できるようになりました。
拡張可能なシステムチェックフレームワーク。開発者がエラー検出時に役立ちます。

これらはまだ氷山の一角にすぎません。最新の Django 1.7 はダウンロードページか PyPI から入手できます。

バグフィックスリリース

Django 1.7 と同時に Django 1.4.15, Django 1.5.10, Django 1.6.7 がバグフィックスのためリリースされました。 Django 1.7 がリリースされたことで Django 1.5 はサポートの対象外となります。 Django 1.5.10 が Django 1.5 シリーズ最後のリリースになります。Django 1.6 は Django 1.8 のリリースまでサポートされます。 Django 1.4 は LTS なので 2015 年 5 月までサポートされます。

https://www.djangoproject.com/weblog/2014/sep/02/release-17-final/

セキュリティリリースのお知らせ (1.6.6)

2014-08-24T09:43:50+00:00

Django 1.4.14, Django 1.5.9, Django 1.6.6, Django 1.7 rc 3 がリリースされました。この記事は https://www.djangoproject.com/weblog/2014/aug/20/security/ を元にしたものです。

このリリースでは reverse() が内部のURLを生成する際の問題、サービス停止を引き起こすファイルアップロード、 remote-user ミドルウェアの潜在的なセッションハイジャックの問題、 Admin インタフェースでの情報漏えいの問題を修正しています。全ての Django ユーザーにできるだけ早いアップグレードが推奨されています。

他ホストへのURLを reverse() が生成し得る問題 (CVE-2014-0480)

Django は django.core.urlresolvers.reverse というヘルパー関数を持っており、 view へのリファレンスかURLパターン名からURLを生成するために使われます。特定条件下で reverse() がスキーム相対 (scheme-relative) な、他のホストへのURLを生成する可能性がありました。これは問題を知っている攻撃者に任意のサイトへのリンクを生成させる可能性があり、フィッシングや他の問題を可能にします。

この修正のため、 reverse() の返り値が '//' で始まる場合は 2 つめのスラッシュが (%2F) で置き換えられるようになりました。

訳注: 元のブログポストを見ると reverse() に '//' で始まる文字列を与えるだけで脆弱性になるように読めますが、特定のURLパターンと一緒でないと起こりえません。ただその文字列が生成された場合に reverse() が特に何もフィルターせずにURLを返していた、というのがこの問題です。例えば '(.+)/foo' のようなURLパターンがあった場合に、このURLにマッチする条件 + '/example.com' という引数を与えると '//example.com/foo' というURLが生成されてしまいます。

サービス停止を引き起こすファイルアップロード (CVE-2014-0481)

デフォルトの挙動で Django のファイルアップロードシステムは、同じファイルパス、同じファイル名でのファイルアップロードが会った際に、新しいユニークなファイル名を生成します。ファイル名に対してアンダースコアと数字を末尾に付与して行い、数字は名前の衝突がなくなるまで順に増やされていきます (_1, _2 など)。

攻撃者は同じ名前をもつ小さいファイルを大量にアップロードすることで、この順によるファイル名生成の脆弱性を攻撃できます。この場合 Django は os.stat() を呼び出すことでファイル名を生成しようとし、この数は増え続けます。結果として、このように割合小さなサイズのファイルのアップロードにしてもパフォーマンスは極端に低下します。

この修正のために、 Djangoのファイルアップロードシステムは順序の数値を使わないようになりました。代わりに短い英数字の文字列が付与されます。

RemoteUserMiddleware のセッションハイジャック (CVE-2014-0482)

Django は REMOTE_USER ヘッダーを認証処理に使うミドルウェア django.contrib.auth.middleware.RemoteUserMiddleware と、認証バックエンド django.contrib.auth.backends.RemoteUserBackend を提供しています。

特定の条件下でこのミドルウェアとバックエンドを使用することで、あるユーザーが別ユーザーのセッションを受信し得るという問題がありました。 REMOTE_USER ヘッダーへの変更が、対応する logout/login アクションなしに起こった場合です。

この修正のためにミドルウェアは、脆弱性をつくようなログアウト以外での REMOTE_USER の変更があった場合に、ログアウトとログインを強制するようになりました。

Admin でのクエリ操作によるデータ漏えい (CVE-2014-0483)

Django の admin インタフェース django.contrib.admin は、関連するオブジェクトをポップアップウィンドウで表示する機能を提供しています。このメカニズムは、URLとクエリストリングに値を保持しておき、表示したい関連モデルとリレーションを実装したフィールドを取得することで実装されていました。これはパーミッションチェックをモデルクラス全体のレベルで行っていました。

しかしこのメカニズムは、特定フィールドが実際にモデル間のリレーションを扱うものかをチェックしていませんでした。よって Admin インタフェースにアクセスでき、モデル構造と該当のURLに十分な理解があるユーザーは関連のないフィールドの値をポップアップ上に表示することができました。アプリケーション開発者が意図していないようなフィールドも表示させれます。

この修正のため admin インタフェースは、通常のパーミッションチェックの追加として、指定されたフィールドが admin に登録されたモデルのリレーションを扱うものかを確認するようになりました。

Django 1.7 リリース候補版 2

2014-07-27T09:43:05+00:00

Django 1.7 rc 2 が公開されました。ダウンロードページ

Django 1.7 にはビルドインのスキーママイグレーションフレームワーク、改良されたプロジェクトの検証ツール、アプリケーションロードの根本的な改善、カスタムのデータベースルックアップなどが含まれます。これらは大きな変更のハイライトで、詳細は開発中の 1.7 リリースノートを参照してください。

Django 1.7 リリース候補版 1

2014-06-28T09:42:28+00:00

Django 1.7 rc 1 が公開されました。ダウンロードページ

セキュリティリリースのお知らせ (Django 1.6.5)

2014-06-01T09:41:42+00:00

5月14日、Django開発チームが Django 1.4.13, 1.5.8, 1.6.5, 1.7 beta 4 をセキュリティリリースの一環としてリリースしました。これらは PyPI とダウンロードページから手に入ります

このリリースはキャッシュポイゾニングを引き起こす問題と、セーフリダイレクト時の正しくないバリデーションチェックの問題を対象にしています。これらの問題は多くのDjango利用者に影響があります。アップグレードが強く推奨されます。

詳細は以下を読んでください。

キャッシュがプライベートデータを保存し、配信される問題 (CVE-2014-1418)

特定の条件下において、 Django があるセッションに関するプライベートデータを保存し、そのデータを別セッションのリクエストに配信するおそれがあります。この問題は情報漏えいと、キャッシュポイゾニングを引き起こします。

Django のセッションを使っている場合、Djangoは Vary: Cookie ヘッダーを設定し、別セッション由来のデータをリクエストに配信しないようにしています。しかし、古いバージョンの Internet Explorer (Internet Explorer 6 か 7 が、WindowsXP か Windows Server 2003 上で動作している場合) では、多くの content types と併せてこの Vary ヘッダーも扱えません。なので、 Django はリクエストが Internet Explorer 由来の場合にこのヘッダーを削除しようとしていました。

この問題を修正するため、この古い Internet Explorer 向けの特殊な動作は削除されました。Vary ヘッダーはレスポンスから消されることはもうありません。追加として、 Content-Disposition ヘッダー付きの Internet Explorer 由来のリクエストへの Cache-Control ヘッダーへの変更も、同様の問題を含むとして削除されました。

特殊なURLがユーザーから指定された場合の、不正確なバリデーション (CVE-2014-3730)

リダイレクト用のバリデーションが、いくつかのブラウザで許可される特殊なURLに対して正確に動作しませんでした。これは安全でない、予期せぬURLへのリダイレクトを許可してしまいます。

Django はいくつかのケースにおいてユーザー入力に依存した「成功時の」リダイレクトを行います (例えば django.contrib.auth.views.login, django.contrib.comments や i18n) これらリダイレクトへのセキュリティチェック (django.util.http.is_safe_url()) は、 http://\djangoproject.com のような特殊なURLに対して正確なバリデートをしませんでした。これはいくつかのURLのパースが寛大なブラウザで許可されていたものです。

この問題を修正するために、 is_safe_url() は、これらの特殊なURLに対しても正常なバリデートを行うように修正されました。

バグフィックスリリースのお知らせ(Django1.6.4)

2014-05-03T09:41:00+00:00

セキュリティリリースが出たばかりですが、functools.partialで作られたviewでreverse()を使った際のバグがあったようです。それによってDjango 1.4.12,Django 1.5.7,Django 1.6.4,Django 1.7 beta 3がリリースされています。

セキュリティリリースのお知らせ(Django1.6.3)

2014-04-22T09:40:02+00:00

本日、Django1.4.11, Django1.5.6, Django1.6.3, Django1.7 beta 2 がセキュリティプロセスの一環としてリリースされました。 PyPI とダウンロードページから入手できます。

このリリースでは、予期しないコードが実行される問題、 CSRF を引き起こす問題、そしてMySQL型キャストの問題を対象にしています。問題が全Djangoユーザーには影響するわけではありませんが、リスク回避のために可能な限り早くアップデートしてください。

問題の詳細は下記を参照してください。

reverse()により予期しないコードが実行される問題

DjangoのURLの扱いは、view callableに対する正規表現マッピング(つまりURLs)をベースにしています。 Django内の処理ではリクエストされたURLを各正規表現のパターンにマッチさせて、実行させるviewを特定しています。

Djangoは上記の処理と逆のことをする django.core.urlresolvers.reverse() も提供しています。 reverse() 関数は view に関する情報をうけとり、viewを実行するためのURLを返します。 reverse() の返り値は常に現在のURLパターンを基本にしているので、アプリケーション開発者には reverse() の使用が推奨されています。これで開発者はURLsを変更しても他のコードを修正しなくて済むようになります。

reverse() への識別子としての引数は対象viewへのドット区切りのPythonパスで表されます。この場合Djangoは結果のURL生成のために、パスが指すモジュールをインポートします。このモジュールがimport時の副作用を含む場合、その副作用が実行されてしまいます。

なのでこれは攻撃者に予期しないコードの実行を許可してしまいます。以下を満たす場合です:

ユーザーインプット由来の値でURLが生成されるviewがある (クエリ文字列中の "next" パラメータで完了ページ(view)を指定している場合などが考えられます)
インポートによる副作用があるモジュールが、サーバー内に存在すると攻撃者に知られている

修正のため、reverse()は、URLパターン内に列挙されているviewを含むパスのみを許可するよう修正されました。このやり方でインポートすると指定したモジュールのみがインポートできるようになっています。

未ログインページのキャッシュによりCSRFトークンが漏れる問題

Djangoはキャッシュフレームワークと、クロスサイトリクエストフォージェリ(CSRF)攻撃を防ぐシステムを提供しています。 CSRFプロテクションシステムは、ランダムな文字列をクッキーでクライアントに送り、その文字列が後にリクエストから返されることを基礎としています。この文字列はformからhidden valueとしてサーバーに返信されます。

キャッシュフレームワークは匿名(未ログイン)クライアントへのレスポンスをキャッシュするオプションを提供しています。

あるページヘの最初の匿名リクエストでクライアントがCSRFクッキーを持っていない場合、キャッシュフレームワークはCSRFクッキーをもキャッシュしてしまい、他のCSRFクッキーを持たない匿名ユーザーへ同じ文字列を送信してしまいます。これは攻撃者に有効なCSRFクッキーを与えることになり、クッキーへのチェックを回避する攻撃を引き起こします。

これの修正として、キャッシュフレームワークはこのようなレスポンスをキャッシュしないようになりました。手順は以下のようになります:

リクエストがクッキーを1つも送信しておらず
レスポンスが1つ以上のクッキーを送信しており、
Varyの場合はクッキーヘッダーがレスポンスに設定されており、レスポンスがキャッシュされていない場合。

MySQL型キャストの問題

MySQLデータベースは特定クエリにおいて'型キャスト'(typecast)するものとして知られています。例えばstring値を含むテーブルに対してinteger値を基本にしたフィルターをした場合、MySQLは暗黙のうちにstringをintegerにし、結果を返します。

適切な型への変換が発生しない場合、クエリ自体に変更が入った場合と変わらないような予期しない結果が返ります。

Djangoのモデルフィールドクラスはそれぞれの型を考慮し、クエリ実行の前にデータベースレベルで正しい型に各クエリ引数を変更します。しかし、以下3つのモデルフィールドは引数を正しく変換していませんでした:

* FilePathField
* GenericIPAddressField
* IPAddrennField

この3フィールドはクエリ実行前に正しい型に引数を変更するよう修正されました。

さらに、カスタムモデルフィールドの開発者に対して適切な型への変換を提供するようドキュメントで注意書きが追加されました。生SQLやSQLフラグメントを可能にするraw(), extra()クエリメソッドの利用者も、クエリ実行前にマニュアルで正しい型に変換するよう注意してください。

(原文は以下にあります。文章におかしなところがあればコメントか @hirokiky に連絡してください https://www.djangoproject.com/weblog/2014/apr/21/security/)

UbuntuのSecurityNoticeではこちら http://www.ubuntu.com/usn/usn-2169-1/

Django 1.7 beta 1 がリリースされました

2014-03-21T09:38:30+00:00

Django 1.7 リリースの一環として、本日 Django 1.7 beta 1 がプレビュー/テスト用パッケージとしてリリースされました。 Django 1.7 での変更を試すことができます。

Django 1.7 では Django にいくつかの新機能が追加され、たくさんの改修が含まれています。ハイライトとしてはスキーママイグレーションフレームワークの取り込み、一般的なエラーを発見、修正する新しいバリデーションツールの追加、 Django がアプリケーションを発見して読み込む方法の抜本的なリファクタリング、カスタムデータベースルックアップの追加です。

詳細なドキュメントは、開発中の 1.7 リリースノートを参照してください。

普段のアルファ、ベータパッケージのように、これは製品で使うものではありません。新機能を試してみたり、バグの発見と修正に協力 (issue トラッカーでの報告を) してくれる場合は、ダウンロードページから入手してください。いつものように、 MD5 と SHA1 チェックサムもあります。

Django 1.7 は現時点で新機能の追加はありません。beta 1 から 1.7 の最終リリースまでの1.7 ブランチでは、バグフィックスと翻訳の更新のみが受け付けられます。

Django1.6.2, 1.7a2がリリースされました

2014-02-15T09:37:32+00:00

元記事: https://www.djangoproject.com/weblog/2014/feb/06/django-162-and-django-17a2-released/

Django1.6.2が1.6シリーズのバクフィックスリリースとしてリリースされました｡ Django1.7a2も1.7リリースの2番目のアルファ版としてリリースされました｡

Django 1.6.2

Django 1.6.2 はバグフィックスリリースとしては2つめのリリースです｡すべてのバグはマイナーなバグフィックスで､リストは Django 1.6.2 リリースノートで参照してください｡

全ユーザーは Django 1.6.2 へのアップグレードが推奨されます｡pipでインストールするか､Django1.6.2をダウンロードページからダウンロードしてインストールしてください｡チェックサムも参照してください｡

Django 1.7 alpha 2

Django 1.7 alpha 2 はプレビュー/テスト用のリリースです｡

Django1.7a2は､新しいシステムチェックフレームワークとアプリケーションのロード方法変更の間で生じた､悪い相互作用を修正するものです｡これによって1.7a1は降板になり､a2が最新版となりました｡

Django1.7の新機能については開発中の 1.7リリースノートを参照してください｡

Django 1.7 alpha 1 がリリースされました

2014-01-27T09:36:30+00:00

Django 1.7 のアルファ版がリリースされました｡ djangoproject.com のブログ記事を翻訳して以下に掲載しています｡

https://www.djangoproject.com/weblog/2014/jan/22/django-17-alpha-1-released/

Django 1.7 リリースプロセスの一環として Django 1.7 alpha 1 がリリースされました｡

1.7 リリースサイクルの初めの一歩であり､Django 1.7 から使える新機能を試すためのプレビュー､テスト用パッケージです｡

Django 1.7 ではたくさんの改善に加えて､いくつかの新機能が追加されています｡ハイライトとしてはスキーママイグレーションフレームワーク､一般的なエラーを発見､修正するのに役立つ新しいバリデーションツール､ Djangoアプリケーションの参照､読み込み方法の抜本的なリファクタリングやカスタムデータベースルックアップなどです｡

より詳細には､開発段階の 1.7 リリースノートを参照してください｡

すべての alpha, beta パッケージと同じように､この Django 1.7 alpha 1 も製品用のパッケージではありません｡新しい機能をちょっと使ってみたい場合や､バグの特定と修正に協力していただけるならアプファパッケージはダウンロードページから入手できます｡ (バグ報告は issue tracker から可能です)

リリースノートに書かれてる以上の追加としては､すでに 2 つの issue が報告されています｡

Issue #21856 -- an empty value for the DATABASES setting will cause a crash.
Issue #21831 -- using the contenttypes package or GenericForeignKey will fail unless django.contrib.auth is in INSTALLED_APPS.

両者とも後の最終的な 1.7 リリースでは修正されます｡

South (有名なサードパーティー製のスキーママイグレーション用パッケージ) ユーザーは 1.7 alpha が South と互換性があると覚えておいてください｡

以上です｡

Django1.6.1がリリースされました

2013-12-15T09:35:20+00:00

先日の12日にDjango1.6.1がリリースされました｡

このリリースはマイナーなバグ対応のみのリリースだそうで､挙動に影響する大きな変更はないようです｡

リリースノート

Django 1.6 がリリースされました

2013-11-07T09:34:22+00:00

先日 Django 1.6 が正式にリリースされました｡

ダウンロードページ

リリースノートでは新機能の詳細すべてが網羅されています｡ここではハイライトをいくつか紹介します:

Django 1.6 ではデフォルトのプロジェクト/アプリケーションテンプレートが簡略化されました｡さらにクリックジャッキング対策と admin インタフェースがデフォルトで有効になっています｡
Django 1.6 からトランザクションの扱いが改修され､データベースレベルでの自動コミットもデフォルトで有効に変更されました｡この改修には Django 1.5 と非互換な点があります｡ 1.5 スタイルのトランザクションハンドリングからの移行を参照してください｡
Django 1.6 はデーターベースへの持続的接続をサポートしています｡ただしこれはコネクションプーリングとは違います｡同じワーカーによって扱われる別のリクエストをまたいでコネクションを保持できます (保持時間は設定可能です)｡

他にも Python 3 の正式対応や､テストランナーの改修などもされています｡

日本語圏向けのハイライト

Django 1.6 からは django.contrib.localflavor は削除されました｡これは別パッケージに分離されて django-localflavor として利用できます｡

Djnago 1.4.10 リリース

同日､ Python 2.5 互換のバグ対応のために Django 1.4.10 もリリースされました｡

1.6rc1,1.5.5リリース

2013-11-04T09:33:21+00:00

Django1.6rc1, 1.5.5, 1.4.9がリリースされました｡

1.6rc1リリース

Django1.6のリリース候補版(release candidate)がリリースされました｡このパッケージはプレビュー､テスト用のもので､本番環境で使うものではありません｡ 1.6から使える新機能を試してみたい人は使ってみてください｡

もしリリースを阻害するようなバグがでなければ､ Django 1.6 は2週間ほどでリリースされます｡ (だいたい11月5日ごろ)

Django 1.6 rc はダウンロードページから入手できます｡その際にはリリースノートの参照をおすすめします｡

Django 1.6 には Python 2.6.5 から Python 3.x リリースが必要です (ただしPy3はPython 3.2 からの対応です) Python 3 対応の詳細は Python 3 への移行ガイドを参照してください｡

元ブログ記事: https://www.djangoproject.com/weblog/2013/oct/22/16c1/

1.5.5,1.4.9リリース

1.5.5, 1.4.9は軽微なバグフィックスを集めたものです｡先日のバグフィックスをよりうまく扱うようPBKDF2ハッシャーを修正｡その他セキュリティーには関係のないバグをいくつか修正しています｡

元ブログ記事: https://www.djangoproject.com/weblog/2013/oct/24/bugfix-releases/